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D A Design Patent Application (submitted in duplicate). 
Including the following: 

D Provisional Application Cover Sheet. 

^ New or Revised Specification, including pages 1 to 66 containing: 

^ Specification 

^ Claims 

^ Abstract 

CH Substitute Specification, including Claims and Abstract. 

CH The present application is a continuation application of Application No. 

filed . The present appUcation includes the Specification 

of the parent apphcation which has been revised in accordance with the 
amendments filed in the parent appUcation. Since none of those 
amendments incorporate new matter into the parent application, the 
present revised Specification also does not include new matter. 

n The present application is a continuation application of Application No. 

filed , which in turn is a continuation-in-part of Application 

No. filed . The present apphcation includes the 

Specification of the parent application which has been revised in 
accordance with the amendments filed in the parent application. Although 
the amendments in the parent C-I-P apphcation may have incorporated 
new matter, since those are the only revisions included in the present 
apphcation, the present application includes no new matter in relation to 
the parent apphcation. 

A copy of earUer application Serial No. Filed . 



including Specification, Claims and Abstract (pages 1 - @@), to which no new matter 
has been added TOGETHER WITH a copy of the executed oath or declaration for such 
earlier apphcation and all drawings and appendices. Such earher apphcation is hereby 
incorporated into the present application by reference. 



D Please enter the following amendment to the Specification under the Cross-Reference to 
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Related Applications section (or create such a section) : "This Application: 

D is a continuation of D is a divisional of D claims benefit of U.S. provisional 

Application Serial No. filed 



□ Signed Statement attached deleting inventor(s) named in the prior application. 
CH A Preliminary Amendment. 

Kl Nine (9) Sheets of ^ Formal D Informal Drawings. 

D Petition to Accept Photographic Drawings, 
n Petition Fee 

1^ An D Executed ^ Unexecuted Declaration or Oath and Power of Attorney. 

[H An Associate Power of Attorney. 

D An D Executed D Copy of Executed Assignment of the Invention to 

[U A Recordation Form Cover Sheet. 
□ Recordation Fee - $40.00. 
[H The prior appUcation is assigned of record to 

□ Priority is claimed under 35 U.S.C. § 1 19 of Patent AppUcation No. 

filed in (country). 

□ A Certified Copy of each of the above applications for which priority is claimed: 
n is enclosed. 

O has been filed in prior application Serial No. filed . 

□ An □ Executed or □ Copy of Executed Earher Statement Claiming Small Entity Status 
under 37 C.F.R. 1.9 and 1.27 

CH is enclosed. 
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n has been filed in prior application Serial No. filed , said 

status is still proper and desired in present case. 

D Diskette Containing DNA/Amino Acid Sequence Information. 

□ Statement to Support Submission of DNA/Amino Acid Sequence Information. 

□ The computer readable form in this apphcation , is identical with that filed in 

Application Serial Number , filed . In accordance with 37 CFR 

1.821(e), please use the □ first-filed, □ last-filed or □ only computer readable form 
filed in that apphcation as the computer readable form for the instant application. It is 
understood that the Patent and Trademark Office will make the necessary change in 
apphcation number and filing date for the computer readable form that will be used for 

the instant application. A paper copy of the Sequence Listing is D included in the 

originally-filed specification of the instant apphcation, D included in a separately filed 
preliminary amendment for incorporation into the specification. 

n Information Disclosure Statement. 

□ Attached Form 1 449. 

□ Copies of each of the references hsted on the attached Form PTO-1449 are 
enclosed herewith. 

□ A copy of Petition for Extension of Time as filed in the prior case. 

n Appended Material as foUows: • 



^ Return Receipt Postcard (should be specifically itemized). 
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FEE CALCULATION: 



n Cancel in this application original claims . 



of the prior application before 



calculating the filing fee. (At least one original independent claim must be retained for 
filing purposes.) 





SMALL ENTITY 



RATE 



FEE 



NOT SMALL ENTITY 



RATE 



FEE 



PROVISIONAL APPLICATION 



$75.00 



$150.00 



DESIGN APPLICATION 



$155.00 



$310.00 



UTILITY APPLICATIONS BASE FEE 



$345.00 



$690,00 



UTILITY APPLICATION; ALL CLAIMS 
CALCULATED AFTER ENTRY OF ALL 
AMENDMENTS 



TOTAL 
CLAIMS 



No, Filed 



73 



■20-- 



No. Extra 



53 



$9 each 



$18 each 



$690.00 




$954.00 



INDEP. 
CLAIMS 



$39 each 



$78 each 



$234.00 



FIRST PRESENTATION OF MULTIPLE 
DEPENDENT CLAIM 



$130 



$260 



ADDITIONAL FILING FEE 



TOTAL FILING FEE DUE 




$1,878.00 



A Check is enclosed in the amount of $ 1.878.00 



The Commissioner is authorized to charge payment of the following fees and to refimd 
any overpayment associated with this communication or during the pendency of this 
application to deposit account 23-3050. This sheet is provided in duplicate. 

D The foregoing amount due. 

^ Any additional filing fees required, including fees for the presentation of extra 
claims under 37 C.F.R. 1.16, 

^ Any additional patent appUcation processing fees under 37 C.F,R. 1 . 1 7 or 1 .20(d). 

□ The issue fee set in 37 C.F.R. L18 at the mailing of the Notice of Allowance. 



The Commissioner is hereby requested to grant an extension of time for the appropriate 
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length of time, should one be necessary, in connection with this filmg or any future filing 
submitted to the U.S. Patent and Trademark Office in the above-identified application 
during the pendency of this appUcation. The Commissioner is further authorized to 
charge any fees related to any such extension of time to deposit account 23-3050. This 
sheet is provided in duphcate. 

SHOULD ANY DEFICIENCIES APPEAR with respect to this application, including 
deficiencies in payment of fees, missing parts of the application or otherwise, the United States 
Patent and Trademark Office is respectfully requested to promptly notify the undersigned. 



Woodcock Washburn Kurtz 
Mackiewicz & Norris LLP 
One Liberty Place - 46th Floor 
Philadelphia PA 19103 
Telephone: (215) 568-3100 
Facsimile: (215) 568-3439 



Date: June 27, 2000 




Peter M. Ullman 
Registration No. 43,963 
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1 SECURE REPOSITORY WITH LAYERS OF TAMPER RESISTANCE 

2 AND SYSTEM AND METHOD FOR PROVIDING SAME 

3 

4 FIELD OF THE INVENTION 

5 The present invention relates generally to the field of computer security 

6 and, more particularly, to a secure repository with layers of tamper resistance, and a 

7 system and method for providing such a repository. 
8 

9 BACKGROUND OF THE INVENTION 

■~ 10 In the field of computer security, one enduring problem is to create a 

^ 11 system that allows an owner of information to electronically distribute the information 

.i; 12 throughout the world while regulating use of that information on remote hardware over 

CI 13 which the information owner has no control. For example, information may be 

P 14 delivered to an end user in encrypted form with the ultimate goal that it be viewed (but 

□ 15 not copied or otherwise misused) by the end user. The information requires a key in 

m 16 order to be decrypted, but it may not be desirable to give the end user unfettered access 

2 17 to the key because the user could then copy the decrypted information and disseminate 

Q 18 it at will. 

19 One solution is not to provide the key directly, but to provide the key to 

20 the end user m the form of software that applies the key (or that performs some other 

21 sensitive function to be hidden from the user). Such software may contain various types 

22 of protection designed to complicate or resist attempts to analyze or misuse the software 

23 or the secrets that the software is designed to protect. However, the drawback to this 

24 solution is that attempts to create "secure" software incorporating such resistance have 

25 so far proven ineffective, as such software has invariably been misused, ported to 

26 unauthorized installations, or broken in one way or another. A further drawback is that 

27 if technology advances to permit greater protection to be built into the software, it is 
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1 not always possible to "renew" the security technology by replacing an old unit of 

2 "secure" software with a new one. 

3 In view of the foregoing, there is a need for a system that overcomes the 

4 limitations and drawbacks of the prior art. 

5 

6 SUMMARY OF THE INVENTION 

7 The present invention provides advantageous systems and methods for 

8 creating and using a software-based secure repository. A black box provided herein is 

9 an exemplary secure repository that uses cryptographic techniques, preferably 

10 public/private key techniques, to perform decryption and authentication services in a 
n secure manner that resists discovery of secret keys used by the cryptographic 

12 techniques. 

13 A secure repository according to the invention, such as the exemplary 

14 "black box" provided herein, functions as the trusted custodian of one or more 

15 cryptographic keys. It performs cryptographic functions such as using a cryptographic 

16 key to decrypt information. A user who wishes to use encrypted information is 

17 provided with a black box that incorporates the key needed to decrypt the information. 

18 The black box contains code that applies the key without actually representing the key 

19 in memory, thus shielding the key from discovery by the user. Preferably, the 

20 information is encrypted with a public key pair that is unique (or substantially unique) 

21 to the user, and each user obtains a unique black box that applies that particular user's 

22 private key. The black box may provide the decrypted information to other software 

23 modules which the black box trusts not to misuse the information or to divulge it in an 

24 unauthorized way. The black box may use cryptographic authentication techniques to 

25 establish trust with these other software modules. 

26 In order to obtain the black box, the user's computer contacts a black 

27 box server, preferably via a network, and uploads a hardware identifier associated with 

28 the computer. The black box server creates an "individualized" black box which 
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1 contains code to apply a particular cryptographic key, where the code (as well as other 

2 code contained m the black box) is based on, and preferably bound to, the hardware 

3 identifier. The black box server may introduce various types of protections into the 

4 code, such as diversionary code, integrity checks, inline encryption, obfuscated 

5 execution, code reorganization, and self-healing code. The black box server then 

6 downloads an executable file or executable library containing the black box for 

7 installation on the user's computer. 

8 In a preferred embodiment, the black box interfaces with an application 

9 program for which it provides secure functions by way of a decouphng interface that 

10 makes the details of the black box transparent to the developer of the application 

11 program. The decoupling interface may, for example, be an application programmer 

12 interface (API) usable with multiple dynamic-link libraries (DLLs), where a different 

13 DLL is linked to the application program at runtime depending on which black box is 

14 being used. A new DLL may be created for a new black box that did not exist at the 

15 time the application program was created. The use of a decoupling interface in this 

16 manner supports a "renewable" model of security - i.e., the black box can be replaced 

17 if it has been found to be defective or unsecure, or if later technological developments 

18 permit the creation of an even more secure black box. The DLL that implements the 

19 decoupling interface is an example of a software module that may be authenticated by 

20 the black box. 

21 Other features of the invention are described below. 

22 

23 BRIEF DESCRIPTION OF THE DRAWINGS 

24 The foregoing summary, as well as the following detailed description of 

25 preferred embodiments, is better understood when read in conjunction with the 

26 appended drawings. For the purpose of illustrating the invention, there is shown in the 

27 drawings exemplary constructions of the invention; however, the invention is not 

28 limited to the specific methods and instrumentalities disclosed. In the drawings: 
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1 FIG. 1 is a block diagram showing an exemplary computing environment 

2 in which aspects of the invention may be implemented; 

3 FIG. 2 is a block diagram showing an exemplary use of a preferred type 

4 of secure repository; 

5 FIG. 3 is a block diagram showing a relationship between a computer 

6 that requests a secure repository and a computer that generates a secure repository; 

7 FIG. 4 is a block diagram of an exemplary secure repository generator 

8 according to aspects of the invention; 

9 FIG, 5 is a block diagram of a cryptographic code generator according to 

10 aspects of the invention; 

11 FIG. 6 is a flow diagram showing an exemplary process for creating a 

12 machine-individualized secure repository; 

13 FIG. 7 is a flow diagram showing an exemplary process for performing 

14 the code creation step of FIG. 6; 

15 FIG. 8 is a block diagram showing an exemplary architecture that 

16 includes a decoupling interface for use with a secure repository and an application 

17 program; 

18 FIG. 9 is a flow diagram showing an exemplary process of using a 

19 secure repository. 
20 

21 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

22 Overview 

23 Modem computing and network technology has permitted widespread 

24 and low-cost electronic distribution of information. One feature of electronic 

25 information is that it is easily copyable and, once it has been delivered to a computer, 

26 the operator of that computer may use and dissemmate the information in ways that are 

27 neither contemplated by, nor consistent with the commercial interests of, the owner of 
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1 the information. A secure repository may be used to control the use of information on 

2 hardware over which the information's owner otherwise has no control. 

3 Computing Environment 

4 As shown in FIG, 1, an exemplary system for implementing the 

5 invention includes a general purpose computing device in the form of a conventional 

6 personal computer or network server 20 or the like, including a processing unit 21, a 

7 system memory 22, and a system bus 23 that couples various system components 

8 including the system memory 22 to the processing unit 21. The system bus 23 may be 

9 any of several types of bus structures including a memory bus or memory controller, a 

10 peripheral bus, and a local bus using any of a variety of bus architectures. The system 

11 memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. 

12 A basic input/output system 26 (BIOS), containing the basic routines that help to 

13 transfer information between elements within the personal computer 20, such as during 

14 start-up, is stored in ROM 24. The personal computer or network server 20 may 

15 further include a hard disk drive 27 for reading from and writing to a hard disk, not 

16 shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic 

17 disk 29, and an optical disk drive 30 for reading from or writing to a removable optical 

18 disk 31 such as a CD-ROM or other optical media. The hard disk drive 27, magnetic 

19 disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard 

20 disk drive interface 32, a magnetic disk drive interface 33, and an optical drive 

21 interface 34, respectively. The drives and their associated computer-readable media 

22 provide non- volatile storage of computer readable instructions, data structures, program 

23 modules and other data for the personal computer or network server 20. Although the 

24 exemplary environment described herein employs a hard disk, a removable magnetic 

25 disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the 

26 art that other types of computer readable media which can store data that is accessible 

27 by a computer, such as magnetic cassettes, flash memory cards, digital video disks. 
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1 Bernoulli cartridges, random access memories (RAMs), read-only memories (ROMs) 

2 and the like may also be used in the exemplary operating environment. 

3 A number of program modules may be stored on the hard disk, magnetic 

4 disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35 (e.g., 

5 WINDOWS® 2000, WINDOWS NT®, or WINDOWS® 95/98), one or more application 

6 programs 36, other program modules 37 and program data 38. A user may enter 

7 commands and information into the personal computer 20 through input devices such as 

8 a keyboard 40 and pointing device 42. Other input devices (not shown) may include a 

9 microphone, joystick, game pad, satellite disk, scanner or the like. These and other 
Q- 10 input devices are often connected to the processing unit 21 through a serial port 

; 

ijf 11 interface 46 that is coupled to the system bus 23, but may be connected by other 

% 12 interfaces, such as a parallel port, game port, universal serial bus (USB), or a 1394 

13 high-speed serial port. A monitor 47 or other type of display device is also connected to 

p 14 the system bus 23 via an interface, such as a video adapter 48. In addition to the 

12 15 monitor 47, personal computers typically include other peripheral output devices (not 

'il 16 shown), such as speakers and printers. 

4 17 The personal computer or network server 20 may operate in a networked 

1:3 18 environment using logical connections to one or more remote computers, such as a 

19 remote computer 49. The remote computer 49 may be another personal computer, 

20 another network server, a router, a network PC, a peer device or other common 

21 network node, and typically includes many or all of the elements described above 

22 relative to the personal computer 20, although only a memory storage device 50 has 

23 been illustrated in FIG. 1. The logical connections depicted in Fig. 2 include a local 

24 area network (LAN) 51 and a wide area network (WAN) 52. Such networking 

25 environments are commonplace in offices, enterprise-wide computer networks, 

26 Intranets and the Internet. 

27 When used in a LAN networking environment, the personal computer or 

28 network server 20 is connected to the local network 51 through a network interface or 
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adapter 53. When used in a WAN networking environment, the personal computer or 
network server 20 typicaUy includes a modem 54 or other means for establishing 
communications over the wide area network 52, such as the Internet. The modem 54, 
which may be internal or external, is connected to the system bus 23 via the serial port 
interface 46. In a networked environment, program modules depicted relative to the 
personal computer or network server 20, or portions thereof, may be stored in the 
remote memory storage device 50. It will be appreciated that the network connections 
shown are exemplary and other means of establishing a communications link between 
the computers may be used. 
Exemplary Use of a Secure Repository 

Referring now to FIG. 2, there is shown an exemplary use of a secure 
repository in connection with remote computer 49. Remote computer 49 is a computer 
that may be able to receive information from other computers, for example by means of 
wide-area network 52 (which may be or comprise the network known as the Internet), 
local-area network 51, or physical delivery on media such as removable magnetic disk 
29 or optical disk 31. Remote computer 49 typically is not in the control or dominion of 
the owner/provider of such information, and thus a secure repository, such as black box 
240, may be used to control the use of information on a computer 49 over which the 
owner/provider of the information otherwise has no control. 

Black box 240 is an exemplary embodiment of a secure repository. Black . 
box 240 comprises code which executes on the general processing means provided by 
remote computer 49 (which may be analogous to the processing means of computer 20 
depicted in FIG. 1, including, but not limited to, processing unit 21). Black box 240 is 
preferably equipped with one or more cryptographic keys 248, and contains code to use 
the cryptographic keys to perform on or more cryptographic fimctions, such as 
decryption of encrypted information 204, and/or authentication of cryptographically 
signed data 212. In an exemplary embodiment, cryptographic keys 248 include 
asymmetric key pairs for use with public/private-key cryptographic methods. 
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1 Preferably, black box 240 also contains code that is designed to ensure that black box 

2 240 performs its cryptographic functions only for trusted software, and in an 

3 environment that resists divulgence of sensitive results or attacks on black box 240 

4 itself. It will be appreciated by those of skill in the art that decryption and 

5 authentication are merely exemplary, and not limiting, of the type of secure or sensitive 

6 functions that could be performed by a secure repository, such as black box 240. 

7 Secure repositories that perform other fiinctions may be installed or employed on 

8 remote computer 49, without departing from the spirit and scope of the invention. 

9 Application program 244 is a software program that also executes on 
Q 10 remote computer 49. FIG. 2 depicts an example where black box 240 performs 
ijfl 11 decryption and/or authentication services for application program 244, which is a 
S 12 program that in some way processes or uses information. In this example, application 

13 program 244 provides encrypted information 204 to black box 240. Black box 240, in 

C 14 turn, decrypts encrypted information 204 (e.g., by using one or more cryptographic 

jL., 15 key(s) 248) and returns decrypted information 208 to application program 244. 

if ^ 16 Similarly, application program 244 may call upon black box 240 to authenticate an item 

111 f: 

s| 17 of data 212, and black box 240 may determine the authenticity of data 212 (e.g., by 

15 18 using one or more cryptographic key(s) 248) and may optionally provide to application 

19 program 244 an indication 216 of whether data 212 is authentic. Encrypted information 

20 204 may, for example, be textual information (e.g., a novel), digital audio (e.g. music), 

21 digital video (e.g., a movie), financial data, software, or any other type of information 

22 (confidential or otherwise). Data 212 to be authenticated may comprise a signed 

23 certificate or other signed information. In a typical use, data 212 includes a certificate 

24 attesting to black box 240 that application program 244 is a sufficiently trustworthy 

25 program (i.e., that application program 244 can be trusted to handle decrypted 

26 information 208 without violatuig rules applying to the usage of decrypted information 

27 208). Data 212 could also comprise a signed "license" to use decrypted information 

28 208, and black box 240 (or trusted decoupUng interface 220 (see below)) may 
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authenticate the signed license to verify that the license is not actually a forgery that has 
been proffered by a user to gain unauthorized access to decrypted information 208. 
Depending on the nature of encrypted information 204, application program 244 may 
be a text-rendering program (i.e., a program that enables the readmg of electronically- 
distributed encrypted text by displaying the text as prmt characters on a monitor), a 
video-rendering program, an audio-rendering program, or any other type of program 
that is capable of processing decrypted information 208 in some manner (or that, for 
any reason, needs to authenticate cryptographically signed information). It will be 
appreciated that the arrangement shown in FIG. 2 is particularly advantageous, because 
it allows application program 244 to make use of cryptographic services (i.e., 
decryption and authentication), without having to know the details of how those 
cryptographic services are performed, or the particular key(s) 248 that are used to 
perform them. 

Associated with remote computer 49 are one or more hardware IDs 224. 
A hardware ID 224 comprises data that identifies, or otherwise relates to, particular 
hardware associated with remote computer 49. Preferably, hardware ID 224 comprises 
one or more of the foUowmg component IDs: CPUID 228, processor serial number 
232, and hard disk ID 236. CPUID 228 may be a unique (or substantially unique) 
pseudo-random number assigned to a central processing unit (CPU) (not shown) of 
remote computer 49 by the manufacture of such CPU. CPUID 228 may be retrievable 
by executing an instruction on such CPU that provides the CPUID to a running 
program. Processor serial number 232 may be a sequentially-assigned number 
associated with a CPU (or other processor) of remote computer 49, which may also be 
retrievable by executing an instruction on such CPU. Some processors may have both a 
CPUID 228 and a serial number 232; other processors may have only one but not the 
other. Hard disk ID 236 may be a number assigned (e.g., pseudo-randomly or 
sequentially) to a hard disk (not shown) associated with remote computer 49. Hard disk 
ID 236 may be assigned by the manufacturer or distributor of such hard disk, and may 



MSFT-0188/154574.1 - 10 - PATENT 

1 be stored in an accessible location on such hard disk. A function of hardware ID 224 is 

2 to provide a number that is uniquely (or substantially uniquely) associated with remote 

3 computer 49. Preferably, hardware ID 224 is based on all of the following component 

4 IDs: CPUID 228, serial number 232, and hard disk ID 236. However, hardware ID 

5 224 may be based on a subset of those component IDs, or on entirely different 

6 component IDs (which may related to different hardware of remote computer 49, or, 

7 perhaps, to the serial number of an operating system (not shown) installed on remote 

8 computer 49). Moreover, hardware ID 224 may comprise the entirety of the component 

9 IDs on which it is based (e.g., a concatenation of the component IDs), a subset of those 

10 component IDs (e.g., the rightmost sixteen bits from each component ID), or may be 

11 derived by a function that generates hardware ID 224 based on the component IDs 

12 (e.g., the multiplicative product of a plurality of component IDs modulo 2^^). It is also 

13 possible to use one of the component IDs itself as a hardware ID 224; for example, 

14 hardware ID 224 could simply be equal to CPUID 228. Preferably, hardware ID 224 

15 cannot easily be retrieved or derived in an environment other than remote computer 49, 

16 such that a program can be constructed that relies on retrieving hardware ID 224 from 

17 the execution environment during execution, thus binding the program to remote 

18 computer 49. Hardware ID(s) 224 may be created/determined in any manner that in 

19 some way relates to the hardware and/or envhonment of remote computer 49, without 

20 departing from the spirit and scope of the invention. Additionally, remote computer 49 

21 may have a plurality of hardware IDs 224, with each hardware ID 224 being based on 

22 different component IDs, or on a different function of the same component IDs. 

23 Black box 240 may access hardware ID(s) 224, and may use hardware 

24 ID(s) 224 in order to perform computations relating to its functions. For example, in 

25 the course of performing a function such as decryption, black box 240 may need to use 

26 a number n. Instead of storing n directly, black box 240 may store n minus the value of 

27 a hardware ID 224. In this case, in order to use the number n, black box 240 would 

28 contain code that that retrieves or computes hardware ID 224 and adds it to the stored 
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1 value to create This has the effect of "binding" black box 240 to a particular remote 

2 computer 49, since it needs a value that can only be accessed on remote computer 49. 

3 As a simple example, if hardware ID 224 is equal to CPUID 228, black box 240 could 

4 execute an instruction to retrieve CPUID 228 and add it to the stored value. In this 

5 case, the instruction will not produce the correct value n unless black box 240 is 

6 executing on the remote computer 49 that has the correct CPUID 228. 

7 It should be noted that black box 240 is designed not merely to perform 

8 sensitive functions in a hidden and protected manner, but also to ensure that the 

9 sensitive results that it produces cannot escape to an untrusted software module - which 

10 means in practice that black box 240 performs the function of authenticating other 

11 software modules that are part of the secure environment in which black box 240 

12 operates. Preferably, black box 240 authenticates every such software module. In 

13 general, each such software module maintains, in a known place, a signed hash of its 

14 code, where the signature is generated with a private key. Cryptographic keys 248 may 

15 include the corresponding pubUc key which may be used by black box 240 to verify 

16 such signatures and establish trust with those software modules. 

17 Black box 240 may communicate directly with application program 244, 

18 or, alternatively, it may communicate through decoupling mterface 220. Decoupling 

19 interface 220 is essentially an intermediary by way of which black box 240 and 

20 application program 244 may communicate using a common language or protocol. The 

21 use of decoupling interface 220 may improve the versatility of a distribution system that 

22 uses black box 240, since it allows application program 244 to conmiunicate with 

23 different types of black boxes 240, and allows black box 240 to communicate with 

24 different types of application programs 244. Additionally, decoupling interface 220 may 

25 authenticate application program 244 to black box 240. As discussed in fiirther detail 

26 below, one issue that arises in the use of a black box 240 that is separate from the 

27 application program 244 for which it provides services is that black box 240 should not 

28 perform sensitive functions for application program 244 unless it is certain that 



MSFT-0188/154574.1 - 12 - PATENT 

1 application program 244 can be trusted to use the sensitive functions only in approved 

2 ways, which means in practice that application program 244 must satisfy the protocol 

3 and other requirements necessary to proffer a trust certificate to black box 240. When 

4 decoupling interface 220 is used, application program 244 need only be able to 

5 communicate with decoupling interface 220, where various embodiments of decoupling 

6 interface can be provided each of which can authenticate application program 244 (and 

7 decoupling interface 220 itself) to a particular black box 240. Decoupling interface 220 

8 may, for example, be provided by the supplier of black box 240 to facilitate 

9 communication between black box 240 and application program 244, as well as to 

10 facilitate the "renewability" of black box 240 (as more particularly discussed below). It 

11 will be appreciated by those skill in the art, however, that while decoupling interface 

12 220 is a convenient and advantageous structure, communications between black box 

13 240 and application program 244 may take place either directly or through decoupling 

14 interface 220 without departing from aspects of the invention. 

15 Provision/ Acquisition of Black Box 240 

16 Remote computer 49 acquires black box 240 from a black box server 

17 304. Black box server 304 may be implemented on a typical computing device, such as 

18 computer 20 (shown in FIG. 1). (Hereinafter, black box server 304 and the computer 

19 20 on which it is implemented shall be referred to interchangeably, unless context 

20 indicates otherwise.) Referring now to FIG. 3, black box server 304 is preferably 

21 connected to remote computer 49 via wide-area network 52. Preferably, wide-area 

22 network 52 is or comprises the network known as the Internet. Black box server 304 

23 includes a black box generator 37a. Black box generator 37a is preferably a computer 

24 program running on computer 20 (such as one of the "other programs" 37 depicted in 

25 FIG. 1). Black box generator 37a receives a hardware ID 224 of a remote computer 49, 

26 and generates a black box 240 that is "individualized" for remote computer 49. 

27 "Individualized" in this context means that the contents of a given black box 240 is at 

28 least partly based on the hardware ID associated with the remote computer 49 for which 
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1 the black box is created, and that a first black box 240 created for a first remote 

2 computer 49 is different from (or, at least, is very likely to be different from) a second 

3 black box 240 for a second remote computer 49. The various black boxes 240 are 

4 "different" in the sense tihat they contain different cryptographic keys 248, different 

5 code to apply the keys 248, and different obfuscating code. The particular ways in 

6 which the black boxes 240 can be made different are discussed more particularly below 

7 in connection with FIG. 4. 

8 In a typical use of black box server 304, remote computer 49 contacts 

9 black box server 304 and transmits to black box server 304 a request for a black box 
] 0 240 via wide-area network 52. The request for a black box may be generated as part of 

11 a registration or "activation" process relating to a particular type of software. For 

12 example, application program 244 may be delivered without a black box 240 that is 

13 needed for its use or some aspect thereof. For example, application program 244 may 

14 be able to work with unencrypted information (or even "keyless sealed" information) in 

15 the absence of black box 240, but may need black box 240 in order to be "activated" 

16 for use with encrypted information 204. In this case, application program 244 may 

17 include activation software 308 which is invoked upon ttie first use of application 

18 program 244, where activation software 308 contacts black box server 304 in order to 

19 obtain a black box 240 which will enable use of application program 244. As another 

20 example, software 308 may be general-purpose web-browsing software by means of 

21 which a user of remote computer 49 may issue a request to black box server 304 by 

22 navigating to a site operated by black box server 304. 

23 The request for a black box 240 that comes from remote computer 49 

24 preferably includes the hardware ID(s) 224 of remote computer 49. Upon receiving the 

25 request, black box server 304 invokes black box generator 37a and proceeds to create a 

26 black box 240 that is at least partly based on hardware ID(s) 224, and is thus 

27 "individualized" for remote computer 49. As discussed above, the black box 240 that is 

28 created will have one or more cryptographic keys 248 associated therewith and hidden 
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1 therein. Once black box 240 has been created, black box server 304 transmits black box 

2 240 via wide-area network 52 to remote computer 49 for installation thereon. 

3 It is particular advantageous to transmit hardware ID 224 and black box 

4 240 via a network such as wide-area network 52 or (if applicable) local area network 

5 51, because this allows a black box 240 to be obtained in "real-time" (e.g., the entire 

6 transaction of requesting, creating, and receiving a black box may take only seconds). 

7 However, it will be appreciated that the use of a network is merely exemplary and not 

8 limited of the means by which information can be exchanged between remote computer 

9 49 and black box server 304. For example, if hardware ID 224 is deemed to be 

10 sensitive information such that there is no network 51 or 52 over which it can be 

1 1 transmitted with sufficient privacy, then remote computer 49 may store its hardware 

12 ID(s) 224 on magnetic disk 29 or optical disk 31 for physical delivery to black box 

13 server 304, or hardware ID 224 may be printed on paper and then physically delivered 

14 to the operator of black box server 304 for entry using keyboard 40. Moreover, the 

15 black box 240 created by black box server 304 may be delivered on magnetic disk 29 or 

16 optical disk 31 for installation on remote computer 49; or it may be delivered via wide- 
ly area network 51 even if hardware ID 224 was not delivered to black box server 304 in 

18 that way. 

19 Black Box Generator 37a 

20 FIG. 4 shows the detail of black box generator 37a. Black box generator 

21 37a comprises a random number generator 404, a code database 408, a key generator / 

22 key database 448, a code generator 440, a compiler 436, and a postprocessor 452. 

23 Random number generator 404 generates random (or pseudo-random) numbers 432, 

24 which are used in the black box generation process as described below. Systems and 

25 methods for generating pseudo-random numbers are known in the art and are therefore 

26 not described herein. Code database 408 contams "diversionary code" for use by 

27 diversionary code generator 416. Code database 408 may also contain templates for use 

28 by cryptographic code generator 412. The nature and use of the code contained in code 
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1 database 408 is further described below. Key generator / key database 448 is an object 

2 that either generates cryptographic keys 248 to be installed in black box 240, or that 

3 stores previously-generated cryptographic keys 248 for installation in black box 240. 

4 Methods of generating cryptographic keys are known in the art, and thus are not 

5 provided herein. Moreover, methods of implementing a database such as code database 

6 408 or key database 448 are also known in the art and thus are not provided herein. 

7 Code generator, as more particularly discussed below, generates the code that 

8 implements the individualized black box 240. Code generator 440 may produce code in 

9 a source language (such as C or C+ +), in which case compiler 436 is used to compile 
^3 ]o the code. If code generator 440 generates executable code directly, then compiler 436 

11 may be omitted. Postprocessor 452, as more particularly discussed below, perfects 

i 12 certain code-obfuscation techniques that are specified at the source level by code 

l^"^ 13 generator 440 but cannot actually be performed and/or implemented until executable 

14 code has been produced. 

Q 15 Code generator 440 generates the code for black box 240. Recalling that 

ill 16 black box 240 is "individualized" for remote computer 49, code generator 440 accepts 

^ 17 as input the hardware ID 224, which is received by black box server 304 at the time 

i3 18 that remote computer 49 requests an individualized black box 240. Code generator 440 

19 generates the code for the black box based on hardware ID 224 - that is, the code that 

20 code generator 440 includes in black box 240 is at least partly determined by hardware 

21 ID 224, such that, all other things bemg equal, different hardware IDs 224 cause code 

22 generator 440 to produce different code. Code generator 440 may also accept as input 

23 one or more random numbers 432, and the code produced by code generator 440 may 

24 be based on random number(s) 432 in the sense that different random number(s) cause 

25 code generator 440 to produce different code. Preferably, code generator 440 accepts as 

26 input both hardware ID(s) 224 and random number(s) 432, and produces code based 

27 both on such hardware ID(s) 224 and such random number(s) 432. However, it will be 

28 appreciated that code generator 440 could use one but not the other, or could use some 
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1 other value as input. It is particularly advantageous, however, for code generator 440 to 

2 use both hardware ID(s) 224 and random number(s) 432, because this has the effect of: 

3 (a) producing a black box 240 with code that is at least partly "random"; and (b) 

4 allowing code to be included in black box 240 that binds black box 240 to hardware 

5 ID(s) 224. The "randomness'' aspect of the code in black box 240 is advantageous 

6 because it helps to ensure that if a first black box 240 is successfully "hacked," the 

7 techniques used to "hack" the first black box 240 are not easily reused on a second 

8 black box 240 that has been generated with a different random number 432. The aspect 

9 of the code for black box 240 being bound to hardware ID(s) 224 is advantageous 

1 0 because it tends to make black box 240 resistant to portability. 

11 Code generator 440 contains various components that handle different 

12 aspects of the code generation process. The components preferably include: a 

13 cryptographic code generator 412, a diversionary code generator 416, a healing code 

14 generator 420, an obfuscating code generator 424, and a code reorganizer 428. In FIG. 

15 4, these components are depicted as separate components of code generator 440. 

16 However, it will be appreciated by those skilled in the art that the implementation 

17 depicted is merely exemplary, as a single component could perform one or more of the 

18 various functions described. Moreover, code generator 440 could contain a subset of 

19 the components depicted, or additional components. Additionally, while separate code 

20 generation and/or code manipulation components are depicted, it should be appreciated 

21 that the code generated by these components need not be or remain separate; the 

22 generated code can be interleaved or combined in any manner. For example, 

23 cryptographic code generator 412 may create a first set of code, and diversionary code 

24 generator 416 may create a second set of code, where the first and second sets do not 

25 necessarily remain as separate contiguous blocks but may be woven together in any 

26 manner. These variations and other may be effected without departing from the spirit 

27 and scope of the invention. 

28 The exemplary elements depicted in FIG. 4 are each discussed below. 
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1 Cryptographic Code Generator 412 

2 Cryptographic code generator 412 generates the code for inclusion in 

3 black box 240 that applies cryptographic keys 248. It will be recalled that a function of 

4 the exemplary black box 240 generated by code generator 440 is to use cryptographic 

5 key(s) 248 to perform decryption and authentication services while hiding key(s) 248 

6 from the operator of remote computer 49 on which black box 240 is to be installed. 

7 Code generator 440 obtains these cryptographic keys from key generator / key database 

8 448 and creates code that hides them in black box. The keys 248 obtained from key 

9 generator / key database 448 may be any type or size of cryptographic keys for use 

10 with any type of cryptographic algorithm. Preferably, cryptographic keys 248 include 

11 asymmetric or "public/private" key pairs for use with public/private key 

12 encryption/decryption and authentication algorithms. One non-limiting and preferred 

13 example of a public/private key algorithm for encryption/decryption and/or 

14 authentication is the RSA algorithm described in U.S. Patent No. 4,405,829 (Rivest, et 

15 al.), although it will be appreciated by those skilled in the art that other public/private 

16 key algorithms could be used. Keys 248 are "hidden" in black box 240 in the sense that 

17 they are never actually represented in numerical form in black box 240. Instead, black 

18 box 240 contains code that performs actions that are functionally equivalent to those 

19 that would be performed by the relevant cryptographic algorithm if keys 248 were 

20 available. Regarding key "hiding" techniques, see generally A, Shamir & N. van 

21 Someren, 'Tlaying Hide and Seek with Keys. " 

22 An understanding of how cryptographic code generator 412 can generate 

23 code that applies keys 248 where the code does not have access to keys 248 begins with 

24 the mathematical principle that some computations involving a given number can be 

25 performed without directly using the number, but merely by using certain properties of 

26 the number. For example, one can determine whether a decimal integer is even or odd 

27 without knowing its entire value, but merely by knowing its least significant digit: a 

28 decimal integer is even if and only if its least significant digit is 0, 2, 4, 6, or 8 (or, in 
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1 the case of a binary integer, if and only if its least significant bit is 0). One can 

2 determine whether a number is negative or non-negative without examining the entire 

3 number, but merely by examining the sign of the number. The number's least 

4 significant digit (or bit) and its sign are "properties" of a number, which, in the 

5 foregoing examples, may be all that one needs to know about the number in order to 

6 compute the information desired. Thus, a program might receive a secret number as 

7 input, where the program performs a first action if the number is negative and a second 

8 action if the number is non-negative. In this example, the program could be constructed 

9 to store only the sign bit of the number. Alternatively, instead of storing any 

10 information about the number, the program could read the sign bit and then represent it 

11 in memory by dynamically creating code that (non-obviously) produces either 0 or 1 

12 depending on what the sign bit is, where any portion of the program that needs to know 

13 the sign bit simply executes the dynamically-created code instead of retrieving the sign 

14 bit from memory. This is a simple example of how a program can be constructed to use 

15 a number without storing the number in memory or otherwise exposing the number to 

16 discovery by a user. 

17 Analogously, cryptographic code generator 412 of the present invention 

18 makes use of mathematical properties of a particular cryptographic key 248, and creates 

19 code that computes the decrypted message that results from applying key 248 to a given 

20 ciphertext message without actually using key 248 itself or otherwise requiring access 

21 to key 248. Cryptographic code generator 412 similarly creates code that uses key 248 

22 to validate cryptographic signatures - again, without requiring access to key 248. An 

23 explanation of the mathematics used in generating code to apply key 248 without 

24 accessing a copy of key 248 is provided in Appendix A below. In addition to the 

25 technique discussed in Appendix A, an additional key-hiding technique that may be 

26 used is to embed a random number in the code for black box 240, and to use that 

27 random number together with hardware ID 224 as a seed for a pseudo-random number 

28 generator; as the pseudo-random number generator produces numbers, bytes of a 
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1 particular key may be plucked out of the number stream as needed by the cryptographic 

2 calculation. 

3 FIG. 5 shows the detail of an exemplary cryptographic code generator 

4 412. Cryptographic code generator includes a key analysis module 504 and a code 

5 producing module 508 that produces the actual code that applies key 248. The key 248 

6 obtained from key generator / key database 448 is received by cryptographic code 

7 generator 412 for analysis by key analysis module 504. Key analysis module 504 

8 performs an analysis of key 248 in light of both its numerical properties and the 

9 cryptographic algorithm that will be used to apply it to a ciphertext message (or, in the 
^5 10 case of authentication, to apply it to a digital signature). Key analysis module may 

11 identifies one or more properties or "attributes" of key 248 and produces or identifies 

i 12 one or more actions and/or functions 512 that would be performed by a cryptographic 

ri 13 algorithm in the course of applying a key 248 having the identified attributes. For 

P 14 example, suppose that key analysis module 504 determines that the forty-second bit in 

i3 15 the binary representation of key 248 is a one (i.e., "on"), and key analysis module 504 

16 is programmed with information that a particular action/function 512 is always 

^ 17 performed by a particular cryptographic algorithm whenever that algorithm applies a 

□ 18 key whose forty-second bit is a one. This action/function 512 can be identified by key 

19 analysis module 504 and provided as input to code producing module 508. Key analysis 

20 module 508 may identify any number of attributes of key 248, and may provide all of 

21 the actions/functions 512 correspondmg to these attributes to code producing module 

22 508. 

23 Code producing module 508 receives the actions/functions 512 that it 

24 will need to perform in order to apply key 248. It will be appreciated by those skilled in 

25 the art that it is possible to write a large - possibly infinite - variety of code that 

26 performs a given action or function 512. It will moreover be appreciated by those 

27 skilled in the art that, given a particular action or function 512, it is possible to generate 

28 different code to perform that function where the particular code generated is based on 



MSFT-0188/154574.1 - 20 - PATENT 

1 factors other than the action or function itself. In the example shown in FIG. 5, these 

2 "other factors" include hardware ID 224 and/or random number 432, Specifically, for 

3 each action or function 512, code producing module 508 produces code that performs 

4 such action or function 512, where the particular code produced is based on hardware 

5 ID 224 and/or random number 432. 

6 Code producing module 508 can produced code based on hardware ID 

7 224 and/or random number 432 m two ways. First, code database 408 may contain a 

8 plurality of alternative programs that perform the same action or ftmction 512. For 

9 example, code database 408 may contain five different programs that perform a certain 
] 0 aspect of exponentiation, with each of the programs having been written by a human 

11 being and stored in code database 408. In this case, code producing module 508 may 

12 select a particular one of these five different programs based on the value of hardware 

13 ID 224 and/or random number 432. Second, code producing module 508 may generate 

14 code to perform an action or function 512 without the need to resort to a selection of 

15 human written code, but rather may write the code itself on an as-needed basis, 

16 Techniques for automated generation of code by machine are known in the art and 

17 therefore are not provided herein. Code producing module 508 may use automatic code 

18 generation techniques to generate code, where the particular code produced is based on 

19 hardware ID 224 and/or random number 432. 

20 In addition to using hardware ID 224 as a parameter that merely 

21 determines the particular code used to perform certain actions or functions 512, code 

22 producing module may also produce code that specifically binds the produced code to a 

23 remote computer 49 having hardware ID 224, For example, certain critical values 

24 stored in the code could be increased by the value of hardware ID 224, and code could 

25 be created to retrieve hardware ID 224 directly from the hardware of remote computer 

26 49 and subtract the retrieved hardware ID 224 from those stored values, where the 

27 critical value itself is the result of the subtraction. In this event, the code produced will 

28 not work (or will behave unexpectedly) unless the machine on which it is running 
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1 provides access to the correct hardware ID 224. There are a multitude of possibilities as 

2 to how code may be built to rely on hardware ID 224 or otherwise to bind the code to 

3 hardware ID 224, and any of those possibilities may be used without departing from the 

4 spirit and scope of the invention. 

5 Diversionary Code Generator 416 

6 Returning now to FIG. 4, code generator 440 includes a diversionary 

7 code generator 416. Diversionary code generator 416 adds to black box 240 

8 "diversionary code." The code produced by diversionary code generator 416 is 

9 "diversionary" in the sense that it performs computations - possibly an enormous 

10 quantity of computations - which preferably achieve no resuh of any importance to 

11 black box 240' s function(s) of applying cryptographic keys 248 to encrypted 

12 information 204 or authenticatable data 212. While execution of the code produced by 

13 diversionary code generator 416 may produce no meaningful result, the code itself 

14 serves a purpose: it serves to confound attempts by hackers to analyze the code of black 

15 box 240. If one (e.g., a "hacker") begins with no knowledge of how black box 240 will 

16 perform its function, it is difficult or impossible to look at a particular piece of the code 

17 of black box 240 and determine whether it is the part of the code that performs sensitive 

18 fimctions, or merely the red herring produced by diversionary code generator 412. The 

19 code produced by diversionary code generator 412 may appear to be producing 

20 intermediate results used in the course of performing sensitive functions, where those 

21 results may never actually be used in the cryptographic process. Thus, one who is 

22 attempting to analyze the code of black box 240 will have to wade through (possibly) 

23 enormous amounts of code before finding the crucial part of the code that performs 

24 sensitive functions. 

25 The code added to black box 240 by diversionary code generator 416 

26 may be stored in code database 408. For example, code database may contain a 

27 gigabyte of computationally-intensive code, and diversionary code generator 416 may 

28 retrieve, for example, ten megabytes of this code for inclusion in black box 240. The 
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1 particular ten megabytes of code retrieved may be based, for example, on hardware ID 

2 224 and/or random number 432. The code stored in code database 408 for use by 

3 diversionary code generator 416 may, for example, be obtained from computationally- 

4 intensive programs that were written for purposes otherwise unrelated to black box 240. 

5 Although any code may be used, the code is preferably computationally-intensive, and 

6 preferably chosen to appear to a hacker as if it is doing something of importance to the 

7 cryptographic functions that black box 240 implements. For example, inasmuch as 

8 public/private key cryptographic algorithms rely heavily on exponentiation, code could 

9 be chosen from programs that perform mathematical computations involving large 

3 10 amounts of exponentiation. Alternatively, instead of using code stored in code database 

D 

11 11 408, diversionary code generator 416 could programmatically generate the diversionary 

C 12 code. 

13 The code produced by diversionary code generator 412 may be included 

P 14 in black box 240 in a variety of ways. For example, the code that actually implements 

3 15 the cryptographic process could be scattered throughout the diversionary code. As 

il 16 another variation, instead of making the code that implements the cryptographic process 

17 completely non-dependent on the diversionary code, diversionary code could comprise 

3 18 computationally intensive code that always (but non-obviously) produces the number 

19 one and stores it in a register (although the code may appear to one unfamiliar with it as 

20 if it might be capable of producing some other value). The register could then be 

21 multiplied by a value used during the cryptographic process. This may have the 

22 beneficial effects of (a) making it appear to a hacker as if the diversionary code is 

23 actually performing some computation of use in the cryptographic process, thereby 

24 making it difficult to distinguish the diversionary code from the "real" code, and (b) 

25 causing the black box 240 to produce imexpected results if the diversionary code is 

26 modified (e.g. if it is modified in such a way that it no longer produces the number 

27 one). 
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1 Healing Code Generator 420 

2 Code generator 440 includes a healing code generator 420. Healing code 

3 generator 420 creates code that uses "error-correction" principles to detect "patches'' 

4 (i.e., additions or modifications to the code of black box 240 that were not part of that 

5 code as originally constituted). Healing code generator 420 may also create code that 

6 can be used to "repair" those patches by dynamically "re-modifying" the code of black 

7 box 240 to restore it to its original configuration (or to some intermediate state that 

8 exists (or should exist) during the execution of the black box 240 program). 

9 In a conventional context, error-correction principles are employed to 

10 correct errors brought about by noise during data transmission. Application of these 

11 error correction principles to executable code is based on the notion that executable 

12 code, like any other data, is merely a sequence of bits. Therefore, minor modifications 

13 to the code (or any other data) can be detected and corrected - whether the 

14 modifications are brought about innocently by random noise, or nefariously by 

15 deliberate attacks on the code (or data). In order to create healing code, healing code 

16 generator 420 may incorporate one or more error correcting codes into the code for 

17 black box 240 as part of the individuaUzation process. These error correcting codes 

18 (ECCs) may include linear codes (such as Hamming codes), cyclic codes (such as BCH 

19 codes) and Reed MuUer codes. The code generated by healing code generator 420 can 

20 detect tampering based on parity checks and on the error syndrome that is calculated 

21 based on code and data in black box 240. Based on the calculated error syndrome, the 

22 code generated by healing code generator 420 may either correct the modification to the 

23 code, or effectively destroy the executing code by effecting other changes to the code 

24 that will cause incorrect operation of the black box 240 program. The code generated 

25 by healing code generator 420 may be designed to detect/heal tampering both as to the 

26 initial state of the black box 240 program (i.e. , the state of the black box 240 program 

27 immediately after loading it into memory) and/or the rumiing state of the program (i.e., 

28 the state of the execution space of the program at some intermediate point during its 
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1 execution). Additionally, as part of the individualization process, healing code 

2 generator 420 may create error correcting code based on a random number and/or 

3 hardware ID 224. 

4 Obfuscating Code Generator 424 

5 Code generator 440 includes an obfuscating code generator 424. 

6 Obfuscating code generator 424 creates code that complicates examination and 

7 modification of the functions performed by black box 240. It will be appreciated that 

8 code produced by other components of code generator 440 is already considerably 

9 resistant to analysis. As noted above, the code that applies key 248 resists discovery of 

10 the key due to the fact that the key is never stored. Additionally, the "diversionary" 

1 1 code makes it difficult to discover which code is performing the sensitive cryptographic 

12 functions. Obfuscating code generator 424 adds an additional layer of protection to 

13 black box 240. 

14 Obfuscating code generator 424 complicates analysis and/or modification 

15 of black box 240 by such techniques as: encrypting portions of the code of black box 

16 240; introducing "mtegrity checks" into black box 240; and/or obfiiscating execution of 

17 code segments (e.g., by loading the code into scattered, randomly-located portions of 

18 memory for execution). Obfuscatmg code generator 424 selects portions of the code of 

19 black box 240 to be protected by encryption, integrity checks, and obfuscated 

20 execution. Preferably, the encrypted portions include the portions of the code that 

21 perform the most security-sensitive cryptographic functions performed by black box 

22 240, but also include other portions in order to complicate the identification of the truly 

23 crucial portions of the code. (I.e., if only the most sensitive portions were encrypted, 

24 then it would be easy for a hacker to locate the most sensitive portions sunply by 

25 looking for encrypted code; therefore, these portions can be hidden by encrypting 

26 unimportant portions of the code including, but not limited to, the diversionary code 

27 produced by diversionary code generator 416.) Additionally, obfuscating code 
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1 generator 424 selects segments of the black box code to be preserved by integrity 

2 checks and obfuscated execution. 

3 As noted above, the code generated by code generator 440 is preferably 

4 in a source language, such as C or C+ + . One method of introducing the above- 

5 mentioned security protection into code that is created in a source language is to use a 

6 software development tool such as a "secure coprocessor simulation" ("SCP") toolkit. 

7 The following is a brief description of an SCP system, which is an exemplary tool used 

8 by obfuscating code generator 424 to introduce protections into the code of black box 

9 240. 

10 SCP: Overview 

1 1 The SCP system works at the source-code level by creating a number of 

12 classes called SCPs, each of which supports an API for security operations such as 

13 encryption, decryption, integrity verification, and obfuscated execution. Operations 

14 such as encryption and checksum computation handle relocatable words, so that the 

15 SCP system may work whether or not code is relocated (e.g., as with DLLs). 

16 To protect an application with the SCP system, one must have access to 

17 the application source code. Although the entity with access to the source code may be 

18 a human program, this need not be the case. Specifically, an automatic code generator, 

19 such as the code generator 440 used to create black box 240, may also use the SCP 

20 system to insert protections into code. The entity (i.e., human programmer or code 

21 generator) performs the following steps to use the SCP system to protect code: 

22 1. SCP macros and labels are inserted into the source file(s) to be protected. 

23 These macros and labels indicate code sections to be protected by such 

24 measures as encryption, integrity verification, and obfuscated execution. 

25 2. Places in the source code are selected where functions such as obfiascated 

26 execution, integrity verification, decryption, and other SCP functions are to 

27 be performed. SCP macros and calls are inserted mto the source code at 

28 these selected placed to perform these actions. 
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1 3. SCP files are added to the application and/or compiled with the application 

2 source code to yield an application executable (e.g, , a .EXE or .DLL file). 

3 4. A post-processing tool (e.g., postprocessor 452) is run on the application 

4 executable file. The post-processing tool may locate sections of the 

5 executable file to encrypt, checksum, or otherwise process in the executable. 

6 The post-processing tool may also randomly (or pseudo-randomly) generate 

7 cryptographic keys, encrypt the code, scatter some keys throughout the 

8 executable file's code (i.e., ".text") section, and perform other setup 

9 actions. 

10 The follow sections describe exemplary features of the SCP system. 

11 SCP: Code-integrity verification 

12 A programmer (or code generator 440) may checksum any number of 

13 (possibly overlapping) application segments at any time during execution. SCP provides 

14 two verification methods, which are accessed via a macro-based API that generates 

15 appropriate functions and data in the protected application's code (.text) section. The 

16 SCP system may, for example, assume that only one code section exists and that its 

17 name is ".text," as is typically the case with standard WIN32 executables. Verification 

18 checks can be inlined (as described below) to avoid exposing boolean return values and 

19 single points of attack. 

20 Method 1: This method works with overlapping segments. The 

21 programmer or code generator marks a region to be verified by inserting the macros: 

22 BEGIN_VERIFIED_SEGMENT(ID1 , ID2) 

23 and 

24 END_VERIFIED_SEGMENT(ID1 , ID2) 

25 inside functions, and adding the macro 

26 VERIFIED_SEGMENT_REF(ID 1 , ID2) 

27 outside of functions. The former two macros mark regions, and the latter macro creates 

28 a "segment-reference function" that returns the region's addresses and checksum. The 
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1 variable (IDl, ID2) is a unique two-byte segment identifier, and checksums are pre- 

2 computed in order of the IDl values of regions; this is to allow cross-verification of 

3 code regions by ensuring a definite order of checksum computation and storage in the 

4 code section. To verify a region, the programmer or code generator inserts a function 

5 such as 

6 SCP.VerifySeg(VerifiedSegmentReflDl_ID2), 

7 which returns a boolean value and makes available both the valid checksum and the 

8 computed checksum (which must match if the code segment is intact). Any SCP object 

9 can verify any segment. 

10 Method 2: The second method works only with non-overlapping 

11 segments. The programmer or code generator specifies a section to be verified using 

12 the macros 

13 BEGIN_VERIFIED__SECTION(Section, IDl, ID2) 

14 and 

15 END_VERIFIED_SECTION(Section, IDl, ID2) 

16 which must be placed outside of functions. The variables (Section, IDl, ID2) specify a 

17 unique section name and a pair of identifier bytes. The programmer or generator can 

18 verify a section by inserting into the source code a function call such as 

19 SCP.VerifyAppSection(BeginSectionIDlJD2, EndSectionIDl_ID2) 

20 both to obtain a boolean verification value and two checksums, as above. 

21 It should be noted that integrity checks can be performed in a way that is 

22 dependent on hardware ID 224, such that black box 240 will not operate properly if it 

23 is running on the wrong machine. 

24 SCP: secret scattering 

25 Method 2 above uses cryptographic keys scattered using a subset-sum 

26 technique. Each key corresponds to a short string used to compute indices into a 

27 pseudo-random array of bytes in the code section, retrieve the bytes specified by the 

28 indices, and combine these bytes into the actual key. 
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1 SCP: Obfuscated function execution 

2 Using labels and macros, the programmer or code generator may 

3 subdivide a function into any number of blocks that the SCP system encrypts. When the 

4 function runs, SCP preferably uses multiple threads to decrypt each block into a 

5 random memory area while executing another block concurrently. Code run m this 

6 manner is preferably self-relocatable. For example, one way to hnplement self- 

7 relocatable code on the Intel x86 platform is to make all function calls via function 

8 pointers. Alternatively, code could be relocatable by means of dynamically adjusting 

9 call offsets during execution. 

10 SCP: Code encryption and decryption 



ijp. 

\J\ 11 The programmer or code generator can specify any number of code 



12 regions to be encrypted by enclosing them within the macros 

13 BEGIN_ENCRYPTED_SEGMENT(ID1 , ID2) 

14 and 

15 END_ENCRYPTED_SEGMENT(ID1, ID2) 

16 and adding the macro 

17 ENCRYPTED_SEGMENT_REF(ID1 , ID2) 

18 outside encrypted regions. These macros and the previously described macros for 

19 verified segments serve sunilar purposes. If a verified region with the identifier (IDl, 

20 ID2) exists, its checksum is used as the encryption key for the corresponding encrypted 

21 segment (i.e., the one with identifier (IDl, ID2)). The programmer or code generator 

22 calls for a segment to be decrypted prior to its execution (by inserting appropriate SCP 

23 call(s)), and can then re-encrypt the segment (also using appropriate SCP call(s)). 

24 Encrypted segments may overlap, and may preferably be encrypted based on their order 

25 of appearance in the source code. 

26 SCP: Probabilistic checking 

27 Each SCP class has its own pseudo-random-number generator that can be 

28 used to perform security actions such as integrity verification only with certain 
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1 probabilities. Additionally, SCP macros may be available that produce pseudo-random 

2 generators inline for this function, as well as for any other function that requires 

3 pseudo-random numbers. 

4 SCP: Boolean-check obfuscation 

5 Several SCP macros provide means of hiding boolean verification of 

6 checksums. In particular, SCP macros or objects may use checksums to mangle stack 

7 and data, and compute jump addresses and indices into simple jump tables, so that 

8 boolean checks become implicit and non-obvious. 

9 SCP: Inlining 

10 To avoid single points of attack, SCP provides macros for inline integrity 

11 checks and pseudo-random generators. These macros may essentially duplicate the code 

12 from the SCP segment-verification functions. 

13 Code Reorganizer 428 

14 Code generator 440 may include a code reorganizer 428. Code 

15 reorganizer 428 reorders or resequences the code that has been produced by the other 

16 components of code generator 440. For example, code reorganizer 428 may move 

17 instructions in the code into a different sequential order, and then add jumps (such as 

18 "conditional" jumps that test for a condition that is always, but non-obviously, true. 

19 Other Features of Code Generator 440 

20 Code generator 440 has some features that cut across the exemplary 

21 components depicted in FIG. 4. For example, code generator 440 may create different 

22 code to perform the same function within black box 240. This technique has the effect 

23 of obfuscating the function being performed, since one must perform an analysis of the 

24 different code segments in order to determine whether they are functionally equivalent. 

25 Additionally, the differing code segments may be "inlined," so as to guard against 

26 single point attacks. Other techniques that may be used by code generator 440 including 

27 introducing timing loops (to detect "hijacking" of calls by an outside program), or 

28 "interleaving" data, state and code by hashing and jumping on the result (which may 
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1 have the effect of making local modification more difficult). Code generator 440 may 

2 create code that implements techniques aimed at detecting observation of black box 240 

3 by a kernel-level debugger; such techniques may include changing debug registers, 

4 checking to see if debug registers were changed, trapping randomly and examining 

5 stack addresses. Moreover, code generator 440 may create non-sensitive code for black 

6 box 240, such as routine code that performs the startup and shutdown of black box 240, 

7 or that performs routine "housekeeping" tasks (although this "routine" code may still 

8 be protected by techniques such as those introduced by obfuscating code generator 

9 424). 

10 Code generator 440 may also produce "diversionary data" for inclusion 

11 in black box 240. Like the "diversionary code" discussed above, diversionary data is 

12 not of direct relevance to the functions that black box 240 performs, but serves to 

13 complicate analysis of black box 240. Diversionary data may include data that is never 

14 used, data that is used exclusively by diversionary code, or as input to functions which 

15 are designed to nullify the effect of the diversionary data. An additional feature of the 

16 diversionary data is that, since its quantity can be varied, it has the effect of shifting the 

17 address of black box 240 's useful code between different instances of black box 240, 

18 which makes it less likely that a successful attack on one black box will aid an attack on 

19 another black box. 

20 Compiler 436 

21 Compiler 436 is used when code generator 440 creates code in a source 

22 language instead of machine-executable code. For example, in an exemplary 

23 embodiment code generator 440 creates code in the C + + programming language, and 

24 compiler 436 is or comprises a C-H -h compiler. Compiler 436 receives the source code 

25 produced by code generator 440 and converts it into executable code. Compilers are 

26 well-known in the art and commercially available, and therefore are not discussed in 

27 detail herein. Compiler 436 may be a specially-configured compiler included in black 
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1 box generator 37a, or it may be a general purpose compiler that is separate from black 

2 box generator 37a, 

3 Postprocessor 452 

4 The SCP tool discussed above provides a convenient means to specify 

5 certain code security techniques, such as inline code encryption, integrity verification 

6 (e.g., checksums), and obfuscated execution of code. However, certain aspects of these 

7 techniques cannot be performed directly on source code. For example, it is not possible 

8 to encrypt source code prior to compilation. Instead, portions of the executable code to 

9 be encrypted can be delunited in the source file, but the actual encryption must await 
3 10 creation of the executable code. Similarly, segments to be protected by integrity checks 
ijt 11 can be delimited in the source, but the actual creation of the mtegrity vahie must await 
E 12 creation of the executable, since it is not possible to obtain a hash of the executable 
\^ 13 code (by means of which integrity will be verified) until the source code has been 
P 14 compiled. Postprocessor 452 performs these functions. 

□ 15 Postprocessor 452 performs, for example, the functions of: encrypting 

m 16 the code specified for encryption, computmg integrity vahie, generating cryptographic 

17 keys for the encryption of code, and storing integrity vahies and code decryption keys 

Q 18 in the executable file. 

19 Process of Creating an Individualized Black Box 

20 Referring now to FIG. 6, an exemplary process is shown by way of 

21 which black box server 304 creates and provides a secure repository that is 

22 individuaUzed for remote computer 49, such as exemplary black box 240. First, at step 

23 601, black box server 304 receives the hardware ID 224 associated with remote 

24 computer 49. As previously noted, hardware ID 224 may be received via a network, 

25 such as wide-area network 52, in the form of a request for a black box 240, where the 

26 request comes from remote computer 49. Alternatively, hardware ID 224 may be 

27 received by other means, such as physical delivery on a digital medium (e.g., magnetic 

28 disk 29, optical disk 31, etc.), or on paper for entry by keyboard. Black box server 304 
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1 may use the process depicted in FIG. 6 to create an individualized black box regardless 

2 of how it receives hardware ID 224. Moreover, it will be appreciated by those skilled 

3 in the art that hardware ID 224 is merely exemplary of the type of information that 

4 supports the creation of a black box 240 individualized for remote computer 49. For 

5 example, instead of hardware ID 224, black box server 304 may receive the serial 

6 number of an operating system running on remote computer 49. Any type of 

7 information will suffice, provided that it identifies remote computer 49, or is in some 

8 way related to remote computer 49 or to the environment present on remote computer 

9 49 (e.g., the serial number of the operatmg system installed on remote computer 49). 

10 At step 602, black box server creates the executable code for an 

11 individualized black box 240, where the code created is at least partly based on 
M 12 hardware ID 224. As discussed above, the process of creating this executable code 
in 13 may, for example, be performed by black box generator 37a. An exemplary process by 
=P 14 which step 602 performed is shown in FIG. 7 and discussed in detail below. 

13 15 At step 603, black box server 304 provides the individuaUzed black box 

ill 16 240 to remote computer 49. Black box server 304 may provide black box 240 via, for 

^ 17 example, wide-area network 52, which may be the same network over which black box 

i3 18 server 304 received hardware ID 224, Alternatively, black box server 304 may provide 

19 black box 240 to remote computer 49 by physical delivery of magnetic disk 29 or 

20 optical disk 31, or by any other means by which the executable file(s) in which black 

21 box 240 is contained may be communicated from one computer to another. 

22 FIG. 7 shows an exemplary process for performing the code creation 

23 step 602 depicted in FIG. 6. The process shown in FIG. 7 may, for example, be carried 

24 out by black box generator 37a (shown in FIG. 4). At step 701, black box generator 

25 37a obtains a cryptographic key 248 (or possibly several cryptographic keys) to be 

26 hidden in black box 240. Cryptographic key 248 may, for example, be obtained from 

27 key generator / key database 448. 
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1 At step 702, black box generator 37a analyzes the newly obtained 

2 cryptographic key 248 in order to identify one or more actions that would be performed 

3 in the course of using a given cryptographic algorithm to apply cryptographic key 248 

4 to data. The cryptographic algorithm may either be a decryption algorithm (that uses 

5 cryptographic key 248 to convert ciphertext into cleartext), or an authentication 

6 algorithm (that uses cryptographic key 248 to verify that a particular data was created 

7 by the holder of a particular secret). The particular cryptographic algorithm by which 

8 cryptographic key 248 will be apphed is be taken into account when identifying actions 

9 will be performed in the course of applying cryptographic key 248. As one example, 
i| 10 step 702 may include the act of using key analysis module 504 of cryptographic code 
ij! 11 generator 412 to identify actions/functions 512, as depicted in FIG. 5. 

2 12 At step 703, black box generator 37a generates code to perform the 

: 13 actions identified at step 702. The code generated at step 703 is capable of applying 

P 14 cryptographic key 248 to data, preferably without requking access to cryptographic key 

fl: 15 248 itself. The process of generating code the code may, for example, be carried out by 

iSi 16 code producing module 508 of cryptographic code generator 412, depicted in FIG. 5. 

y 17 Code may be generated programmatically, or it may be retrieved from code database 

18 408. The particular code that is generated or retrieved may be at least partly based on 

19 hardware ID 224 and/or random number 432. Additionally, the code produced may be 

20 designed to rely in some way upon correct dynamic retrieval of hardware ID 224 from 

21 the environment in which black box 240 is intended to run. 

22 At step 704, black box generator 37a generates "diversionary" code for 

23 inclusion in black box 240. Diversionary code may, for example, be stored in code 

24 database 408. A portion of the code stored in code database 408 may then be retrieved 

25 by diversionary code generator 416. The particular code retrieved for inclusion in black 

26 box 240 may be based, for example, on random number 432 and/or hardware ID 224. 

27 At step 705, black box generator 37a generates "healing" code, which is 

28 designed to replace "patches" (i.e., unauthorized modifications to the code of black box 
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1 240) with the originally intended code. The healing code may be generated, for 

2 example, by healing code generator 420. The particular code generated at step 705 is 

3 generally based on other parts of the code to be included in black box 240, since the 

4 code generated at step 705 is specifically designed to replace portions of black box 240 

5 if they become modified. 

6 At step 706, black box generator 37a introduces obfuscation and integrity 

7 measures into the code of black box 240, such as encrypted code, integrity checks, and 

8 obfuscated execution of code. Black box generator 37a may, for example, perform this 

9 function by using obfuscating code generator 424 to introduce the macros and function 

10 calls of the SCP system described above. 

11 At step 707, black box generator 37a reorganizes the code for black box 

12 240, for example by reordering or resequencing segments of the code and introducing 

13 jumps to cause the code to be executed in the correct sequence. The reorganization 

14 may, for example, by performed by code reorganizer 428. 

15 At step 708, the code generated by black box generator 37a at steps 703 

16 through 707 is optionally compiled. Preferably, the code generated at steps 703 through 

17 707 would be generated in a source language such as C or C-f + , in which case it 

18 needs to be compiled. The compilation may, for example, be performed by compiler 

19 436, which is a compiler appropriate for the language in which the code was generated, 

20 such as a C compiler or a C + + compiler. In an alternative embodiment in which black 

21 box generator 37a generates code directly in a machine executable format (e.g., a .EXE 

22 or .DLL file), then it is unnecessary to perform step 708. 

23 At step 709, black box generator 37a performs postprocessing of the 

24 executable code for black box 240. Step 709 may, for example, be performed by 

25 postprocessor 452. As previously discussed in connection with FIG. 4, there are some 

26 aspects of the code obfuscation and integrity measures introduced at step 706 that 

27 cannot be perfected at the source level, but must wait until the executable code has been 

28 produced. For example, one obfuscation measure is to encrypt executable code inline, 
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1 and decrypt it prior to its use. It is not possible to encrypt the executable code until it 

2 has been produced (and it is not possible to encrypt the source code because it will not 

3 compile). Moreover, it is not possible to create the integrity values (e.g., hashes, 

4 checksums, etc.) that are used to implement integrity checks because these measures, 

5 too, require encrypted code. Thus, at step 709 postprocessing of die executable code 

6 produced at step 708 is performed. Specifically, sections of code delimited for 

7 encryption are encrypted, and sections of code marked for integrity checks are hashed. 

8 The keys used for encrypted code may be selected at step 709. The keys may be based 

9 in part on hardware ID 224 and/or random number 432. The particular method of 
7^ 10 performing an integrity check may be based in part on hardware ID 432. 

ill 11 Once postprocessing is complete, black box generator 37a proceeds to 

i 12 step 603 shown in FIG. 6, It will be appreciated fliat, while the steps of FIG. 7 are 

G 13 depicted as taking place in a certain order, certain of the steps shown may take place in 

P 14 a different order. For example, the code generated at step 703 through 705 could be 

irj 15 generated in sequences other than that depicted in FIG. 7. The reorganization of code at 

1=5 1 16 step 707 could take place either before or after the compilation performed at step 708. 

17 Other modification may be made to the order of steps without departing from the spirit 

□ 18 and scope of the invention. 

19 Example Architecture Incorporating Black Box 240 and Decoupling Interface 220 

20 As noted above in connection with FIG. 2, black box 240 and application 

21 program 244 may communicate either directly or through a decoupling interface 220. 

22 FIG. 8 shows an exemplary architecture of a system in which a decoupling interface is 

23 employed for use with black box 240 and application program 244. 

24 Decoupling interface 220 addresses the issue of how black box 240 can 

25 be replaced with another black box 240a, while still permitting communication and 

26 authentication to take place between application program 244 on the one hand, and 

27 black box 240 or 240a on the other hand. Replacement of black box 240 may become 

28 necessary if black box 240 has become damaged (e.g., if a hacker has made a 
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1 deliberate and irreparable attempt to modify black box 240), if black box 240 has 

2 become obsolete due to the development of new secure repository technology (which 

3 may, for example, include either new software techniques or a hardware-based 

4 repository), or if application program 244 may be usable on different types of platforms 

5 having different types of secure repositories. (E.g., an open platform such as a PC 

6 ruiming one of the MICROSOFT WINDOWS 95, 98, NT, or 2000 operating systems 

7 may require a different type/level of security from a closed platform such as a dedicated 

8 text viewing device.) However, it will be noted that application 244 preferably should 

9 be able to interface with any black box - either original or replacement - in at least two 

10 ways. First, application program 244 needs to authenticate itself to the black box, since 

11 the black box should not perform sensitive function for an entity who has not 

12 established trustworthiness. Second, application program 244 needs to be able to 

13 communicate with black box 244 in order to request performance of the sensitive 

14 functions that black box 244 is designed to perform. Decoupling interface 220 provides 

15 a single authentication and communication protocol that application program 244 can 

16 use regardless of the black box being used, thus making the particular secure repository 

17 transparent to the developer of application program 244. 

18 Application program 244 and black box 240 in the exemplary 

19 architecture shown communicate through decoupling interface 220. Decoupling 

20 interface 220 may, for example, be or comprise an application programmer interface 

21 (API) having an "initialization" call and a "bind to license'' call. (Licenses are 

22 explained in further detail below; briefly, a license permits the use of content protected 

23 by black box 240.) The API may be provided in the form of a dynamic-link library 

24 (.DLL) file that is loaded with application program 244 and executes in the process 

25 (i.e., in the address space) of application program 244. Both of the calls provided by 

26 the API may be exposed to application program 244 and implemented by decoupling 

27 interface 220 (i.e., the calls have addresses located in the address space of application 

28 program 244). Additionally, these two calls may preferably provide all of the 
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1 interaction that is necessary in order for application program 244 to make use of black 

2 box 240. For example, the "initialization" call may perform the functions of (a) 

3 authenticating application program 244 to black box 240, and (b) causing decoupling 

4 interface to execute instructions that initialize black box 240 for use and allow black 

5 box 240 to authenticate decoupling interface 220. A purpose of black box 240's 

6 authenticating decoupling interface 220 is to establish a chain of trust. Since decoupling 

7 interface 220 presents appUcation program 244's proffer of trustworthiness to black box 

8 240, black box 240 must trust decoupling interface 220 to perform this authentication 

9 properly (e.g., black box 240 may need to ensure that decoupling interface 220 is not a 

10 rogue DLL presenting a stolen certificate in an unauthorized context). The bind-to- 

11 license call may request that black box 240 perform its sensitive function(s) for 

12 application program 244. In the example depicted in FIG. 8, the sensitive fimction that 

13 black box 240 performs is to enable the use of encrypted licensed data object 800 when 

14 permitted by license 816 (as more particularly described below), and the bind-to-license 

15 call may provide "enabling bits" 824 that allow application program 244 to use licensed 

16 data object 800. 

17 For example, application program 244 may issue an initialization call 

18 (e.g., DecouplingIF::InitO) which is implemented by decoupling interface 220. This 

19 call may cause decoupling interface 220 to execute code that starts black box 240, gives 

20 it an opportunity to authenticate decoupling interface 220, and prepares a secure 

21 environment that discourages modification or observation of black box 240 while black 

22 box 240 is executing. It should be noted that the act of authenticating decoupling 

23 interface 220 is optional, as there may be environments in which the authenticity of 

24 decoupling interface 220 can be presumed from circumstance (such as purpose-built 

25 devices for which all software is in the form of "firmware" installed by the 

26 manufacturer). Black box 240 may take steps to prepare a secure environment, such as 

27 attaching to application program 244 using the DebugActiveProcess system call of the 

28 MICROSOFT WINDOWS 95/98/NT/2000 operating systems, in order to prevent other 
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1 debuggers from attaching. Preferably, decoupling interface 220 does not process the 

2 bind-to-license call until decoupling interface 220 has completed the initialization 

3 process with black box 240. After the initialization process is complete, application 

4 program 244 may issue a bind-to-license call (e.g., DecouplingIF::BindToLicense()), 

5 which causes decoupling interface 220 to execute code that requests black box 240 to 

6 perform its sensitive fimctions for application program 244. In the example of FIG. 8, 

7 the bind-to-license call requests that black box provide enabling bits 824. Black box 240 

8 then provides enabling bits 824 to decoupling interface 220 (assuming that circumstance 

9 permit), and decoupling interface 220 provides enabling bits 824 to application program 

10 244. It will be appreciated that this arrangement allows application program 244 to 

1 1 authenticate itself and request services from black box 240 without knowing the details, 

12 mechanics, or communications protocols needed to interface directly with black box 

13 240. In effect, decoupling interface provides a common language through which 

14 application program 244 and black box 240 may communicate. 

15 Still referring to FIG. 8, in the exemplary architecture shown, data 

16 object 800 is a file that includes encrypted information 204, a sealed key 820, and a 

17 license 816. Sealed key 820 may be the key that decrypts encrypted information 204. In 

18 a preferred embodiment, sealed key 820 is a symmetric key that was used to encrypt 

19 encrypted information 204. License 816 governs the use of encrypted information 204. 

20 For example, license 816 may specify the rights to decrypt and/or render encrypted 

21 information 204. Encrypted mformation 204 may, for example, be the text of a book. 

22 In other examples, encrypted information 204 may be audio or video content, such as a 

23 digital audio file or a digital video file. Application program 244 is a software 

24 application appropriate for the nature of the information contained in data object 800. 

25 For example, if encrypted information 204 is the text of a book, then application 

26 program 244 may be a text-rendering application or "reader" program. If encrypted 

27 information 204 is a digital audio or digital video, then application program 244 may be 

28 an audio-rendering or video-rendering application. 
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1 The exemplary architecture of FIG. 8 includes black box 240. Black box 

2 240 includes a public key 248a, and a corresponding private key 248b. As discussed 

3 above, private key 248b is preferably "hidden" in black box 240, such that no copy of 

4 private key 248b actually appears in black box 240, although black box 240 contains 

5 the code necessary to apply private key 248b. 

6 In the example of FIG. 8, there is shown a certificate 812, which has 

7 associated therewith an asymmetric key pair including a public key 804 and a private 

8 key 808. Private key 808 is not represented directly in certificate 812, but rather is 

9 encrypted with the public key of black box 240. Sealed key 820 is "key"-sealed in data 

10 object 800 with public key 804 of certificate 812 such that it can only be "unsealed" 

11 with private key 808. It will be appreciated that the series of encrypted and sealed keys 

12 establishes a chain of control from black box 240, to certificate 812, to sealed key 820, 

13 to encrypted information 204, such that it is not possible to decrypt information 204 

14 without all of these objects. Specifically, information 204 can only be accessed with 

15 sealed key 820. Sealed key 820, in turn, can only be accessed with private key 808. 

16 Private key 808, in turn, can only be accessed with private key 248a of black box 240. 

17 This is a particularly advantageous arrangement, since it allows access to data object 

18 800 to be tied to the private key 808 of certificate 812, rather than to a particular black 

19 box 240. For example, if black box 240 were replaced with black box 240a (which has 

20 public/private keys 248c and 248d, which are different from public/private keys 248a 

21 and 248b of black box 240), data object 800 could be used by black box 240a without 

22 any modification to data object 800, merely by issuing a new certificate 812a, which 

23 has the same public/private keys 804 and 808, but with private key 808 being encrypted 

24 with public key 248c of new black box 240a, instead of being encrypted with public key 

25 248a of old black box 240. 

26 Exemplary black box 240 depicted in FIG. 8 performs the function of 

27 enabling application program 244 to render encrypted content 204 by providing 

28 "enabling bits" 824 to application program 244. Enabling bits 824 may comprise either 
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1 decrypted content 208 (in which case black box 240 performs the function of applying 

2 key 820 to convert encrypted content 204 into decrypted content 208), or key 820 itself 

3 (in which case application program' 244 uses key 820 to perform the actual decryption 

4 of data object 800). Exemplary black box 240 also perform the function of validating 

5 license 816 to determine whether license 816 permits use of encrypted information 240. 

6 If license 816 does not permit the use of encrypted information 804 (e.g., if license 816 

7 is expired, or if data object 800 is not present in an authorized environment), then black 

8 box 240 does not provide enabling bits 824 to application program 244. 

9 Black box 240 preferably provides enabling bits to application program 

10 244 by way of decoupling interface 220. However, application program 244 and black 

11 box 240 may communicate du^ectly in accordance with aspects of the invention. 

12 Decoupling interface is particularly useful in the example of FIG. 8, because it allows 

13 for simple replacement of black box 240 with black box 240a without requuring any 

14 modification to rendering application 244. Thus, in accordance with aspects of the 

15 invention, black box 240 could be replaced with black box 240a (e.g. , if black box 240 

16 has become corrupted or obsolete) without any change to either rendering application 

17 244 or data object 800 - merely by providing black box 240a with certificate 812a and, 

18 if necessary, replacing the code of decoupling interface 220 to allow it to 

19 communicate/authenticate with black box 240a. (E.g., If decoupling interface 220 is a 

20 dynamically linkable library of executable code (i.e., a DLL) which links to application 

21 program 244 at runtime, the DLL can be replaced with a new DLL. This replacement 

22 may transparent to application program 244, since the calls made by application 

23 program 244 (i.e., InitQ and BindToLicenseQ) would simply reference the new code in 

24 the new DLL.) Thus, the use of decoupling interface 220 is particularly advantageous 

25 because it supports the replaceability of black box 240, and thus supports a 

26 "renewable" model of security. For example, if a hardware-based repository should 

27 become available, decoupling interface 220 may provide communication between the 

28 not-yet-created hardware based repository and application program 244 in a manner 
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1 that is transparent to the developer of application program 244. As another example, 

2 technology for the creation of software-based repositories could progress, thereby 

3 allowing a first software-based repository to be replaced with a second software-based 

4 repository having features that were not present when the first repository was created. 

5 As a further exemplary feature, application program 244 may specify a "type" of 

6 repository that it is able and/or willing to work with, where new repositories of that 

7 "type" may not be in existence at the time that application program 244 is created, but 

8 which may be developed later, thereby further supporting the "renewable" model of 

9 security. 

10 It is possible for black box 240 and application program 244 to 



11 communicate without decoupling interface 220. For example, application program 244 

£ 12 could authenticate itself directly to black box 240 and could receive dnectly from black 

13 box 240 the enabling bits 824 needed to use object 800. However, the use of 

14 decoupling interface 220 is particularly advantageous because it supports the 

15 "renewability" of black boxes, as described above. More particularly, since application 

16 program 244 only needs to be able to communicate through decoupling interface 220, it 

17 does not need to know any of the details about black box 240, such as how to 

18 authenticate itself to black box 240, or what communication protocol is used to 

19 communicate with black box 240. Thus, black box 240 could be replaced with a 

20 different black box 240a, with the change being transparent to the developer of 

21 application program 244. For example, black box 240a may be a different type of black 

22 box for use on a different type of remote computer 49 (such as a dedicate rendering 

23 device), or, as noted above, it may be a black box 240a that incorporates new security 

24 technology that had not been developed at the time that black box 240 was provided to 

25 remote computer 49, or it may be a hardware-based secure repository. It will be 

26 appreciated that the use of decoupling interface 220 enables the use of black box 240a 

27 with application program 244 and data object 800 even if black box 240a has not been 
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1 developed or is otherwise not yet in existence at the time that application program 244 

2 and data object 800 are installed on remote computer 49. 

3 Referring now to FIG. 9, there is shown an exemplary process by which 

4 application program 244 uses black box 240 through decoupling interface 220. At step 

5 901, application program 244 starts execution. Application program 244 may be a 

6 program executing on an open platform or general purpose computer, such as remote 

7 computer 49. Alternatively, application program 244 may be a program for a closed 

8 platform such as purpose-built hardware (not shown). For example, application 

9 program 244 may be a program that displays electronically-distributed text to a (human) 

10 user. One version of application program 244 may be designed to run on general- 

11 purpose open-platform remote computer 49. Another version of application program 

12 244 may be designed to run on a dedicated hand-held reading device that runs no 

13 software other than that necessary to display electronic text. Preferably, application 

14 program 244 loads decoupling interface 220 (e.g., by linking with a DLL that contains 

15 instructions which implement decoupling interface 220), in order to facilitate 

16 communication with black box 240. 

17 At step 902, application program issues an mstruction to initialize black 

18 box 240. Preferably, the initialization instruction is implemented by decoupling 

19 interface 220 and takes the form of a method that decoupling interface 220 exposes to 

20 application program 244. For example, the code of application program 244 may 

21 include an instruction of the form {DecouplingIF::Init()), which executes code to 

22 perform the initialization function (where the code is in the decoupling interface DLL 

23 and linked to application program 244 at runtime). The call to InitQ may, optionally, be 

24 parameterized by data representing a type of black box 240 (e.g., if the developer 

25 and/or provider of application program 244 has deemed that application program 244 

26 should work only with a particular type of black box, decoupling interface 220 may 

27 provided support for such a condition if it is specified as a parameter). Steps 903 and 
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1 904, described below, may be performed as part of, or in response to, the initialization 

2 instruction issued at step 902, 

3 At step 903, decoupling interface 220 proffers to black box 240 proof of 

4 the authenticity and/or trustworthiness of application program 244, The process of 

5 authenticating application program 244 generally includes obtaming a certificate from 

6 application program 244 (where the certificate is signed with the private key of a 

7 trusted certifying authority) and then validating the signature. The certificate may be 

8 located in the code of application program 244 in a place known to the DLL that 

9 implements decoupling mterface 220. Black box 240 preferably incorporates the public 
^ 10 key of the certifying authority. The process of authenticating application 244 may be 

Li 

p 11 particularly simple when the platform on which application 244 is running is a purpose 

I 12 built device or features hardware-enforced isolation, since it may then be presumed that 

13 only trusted applications 244 would be installed on such a device. 

P 14 At step 904, black box 240 is started and, optionally, is given the 

3 15 opportunity to prepare a secure environment, including authenticatmg decoupling 

V, 16 mterface 220 and application program 244. The details of this process depend on the 

17 particular environment in which black box 240 and application program 244 are 

3 18 running. For example, in the case of a closed, purpose built device, the only actions 

19 that may need to take place are retrieving a private key from a ROM and validating its 

20 certificate. 

21 In the case of "authenticated boot" environments, the process may 

22 mclude using an operating system call to check a software image (e.g., of the 

23 decoupling interface 220 DLL), checking the certificate of application program 244, 

24 and isolating the code and data space of application program 244. 

25 In the case of an open platform, such as where application program 244 

26 runs on a typical personal computer using one of the MICROSOFT WINDOWS 

27 95/98/NT/2000 operating systems, the process of authenticating decoupling interface 

28 220 and preparing a secure environment may include the following actions. The 
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1 initialization call of decoupling interface 220 (i.e., DecouplmgIF::Init()) may cause the 

2 code in decoupling interface 220's DLL to issue an initialization call exposed by black 

3 box 240 (e.g. , BlackBox: :Init). Preferably, one of the arguments to BlackBox::Init may 

4 be a binary certificate that contains a cryptographic hash of the code of decoupling 

5 interface 220 signed by the private key of a certifying authority, where the 

6 corresponding public key is available to (e.g., inside) black box 240. Black Box 240 

7 reads the code of decoupling interface 220, for example by using the system call 

8 ReadProcessMemory (or a private in-process protocol that accesses the address space of 

9 decoupling interface 220), and computes its hash and compares it to the one signed by 

10 the certifying authority. BlackBox: :Init may also check that the return address from its 

11 Init call is m the execution space of decoupling interface 220. Decoupling interface 220 

12 may also receive two additional certificates from black box 240: a certificate from a 

13 certifying authority (which may or may not be the same certifying authority that signs 

14 the certificate of decoupling interface 220) binding the name and public key of the 

15 developer of application program 244, and also a binary certificate from the developer 

16 of application program 244 naming the hash, security level and expiration of its code. 

17 Decoupling interface 220, which is in the same address space as application program 

18 244, computes the hash of the application code, verifies die certificate and compares the 

19 computed hash to the signed hash. These action may be performed before decoupling 

20 interface 220 returns from the initialization call issued by application program 244. 

21 Additionally, during the call to BlackBox: :Init, black box 240 preferably 

22 attaches to application program 244 using the DebugActiveProcess system call (or 

23 similar call, when an operating system other than one of the MICROSOFT WINDOWS 

24 operating systems is being used), which has the advantageous effect of preventing user 

25 mode debuggers from attaching to application program 244. Preferably, no sensitive 

26 code withm black box 240, and no key within the black box 240 (e.g., key 248) are 

27 "uncovered" until this attachment is done, internal black box integrity checks are 

28 performed, and the code of application program 244 and/or decoupling interface 220 
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have been authenticated. Thereafter, all sensitive data is "poked" into the application 

2 process (using WriteProcessMemory, or a private in-process interface that accesses the 

3 address space of the application process) and does not travel via COM, RPC or system 

4 buffers. 

5 Preferably, in order to establish a secure environment, system 

6 components used by black box 240, decoupling interface 220, and application program 

7 244 are also authenticated. Components to be authenticated may include user libraries, 

8 kernel components, or any other software that has the potential to affect the security of 

9 the environment in which protected actions are to be performed. 

3 iQ At the conclusion of step 904, establishment of a chain of trust between 

fi 11 black box 240 and application program 244 is complete. Black box 240 may now 

i 12 proceed to perform sensitive functions, such as cryptographic services, for application 

13 program 244. 

p 14 At step 905, application program 244 requests services from black box 

□ 15 240. For example, black box 905 may provide or identify data object 800 and request 

i[ 16 that that data object 800 be decrypted if permitted by license 816. In the case where 

^ 17 decoupling interface 220 is present, application program 244 may make this request 

i 18 through decoupling interface 220, which then issues the necessary instructions to black 

19 box 240. 

20 At step 906, black box 240 performs fimctions necessary to validate 

21 license 816 and provide application program 244 with access to data object 800. For 

22 example, in the exemplary architecture depicted in FIG. 8 where license 816, key 820, 

23 and content 204 are cryptographically "sealed" together, black box 240 may use its 

24 (preferably hidden) private key 248b to decrypt private key 808 of certificate 812, and 

25 then may use private key 808 to unseal data object 800 and read its license 816. Black 

26 box 240 may then proceed to evaluate license 816, checking whatever conditions are 

27 necessary to perform the evaluation. For example, license 816 may permit decryption 

28 of data object 800 up to a particular date, in which case the license evaluation process 
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1 includes checking a (preferably trusted) calendar source. As another example, license 

2 816 may permit data object 800 to be used only in a particular environment (e.g., the 

3 license may permit data object 800 to be used on an isolated hardware device but not on 

4 an open platform), in which case the evaluation process includes the act of identifying 

5 the environment. 

6 If the license permits use of data object 800, black box 240 may obtain 

7 sealed key 820 and use it to provide "enabUng bits" 824 to application program 244 at 

8 step 907. In one exemplary embodiment, enabling bits 824 may include sealed key 820, 

9 which application program 244 uses to object 800's encrypted information 204. In 

10 another exemplary embodiment, black box 240 uses sealed key 820 to convert 

1 1 encrypted information 204 into decrypted information 208 and then provides decrypted 

12 information 208 to application program 244. In the latter example, the decrypted 

13 information itself is the "enabling bits" 824. When decoupling interface 220 is present, 

14 black box 240 preferably provides enabling bits 824 to application program 244 through 

15 decoupling interface 220. 

16 It is noted that the foregoing examples have been provided merely for the 

17 purpose of explanation and are in no way to be construed as limiting of the present 

18 invention. While the invention has been described with reference to various 

19 embodiments, it is understood that the words which have been used herein are words of 

20 description and illustration, rather than words of lunitations. Furdier, although the 

21 invention has been described herein with reference to particular means, materials and 

22 embodiments, the invention is not intended to be limited to the particulars disclosed 

23 herein; rather, the invention extends to all functionally equivalent structures, methods 

24 and uses, such as are within the scope of the appended claims. Those skilled in the art, 

25 having the benefit of the teachings of this specification, may effect numerous 

26 modifications thereto and changes may be made without departing from the scope and 

27 spirit of the invention in its aspects. 
28 
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1 APPENDIX A 

2 Background 

3 Let e be the exponent to be computed. 

4 Let %^ be the exponent of the "accumulation," the number that 

5 accumulates the message raised to e. 

6 Let e^xx current error exponent. 

7 When using the bmary method to compute an addition chain, e is 

8 scanned from left to right. For each scanned bit, the accumulation is squared, which 

9 doubles its exponent (the shift stage: = %c < < 1). If the scanned bit is 1, the 
:f| 10 accumulation is then multiphed by the message, which increases its exponent by 1 (the 
:i; 11 add stage: = e^^^ + l). This process may be characterized as shifting the MSB off 
i J ^2 e and on to e^^^- The add stage effectively corrects the exponent error that accumulated 

13 when the exponent was left shifted. 

14 The m-ary method generalizes this method by shifting m bits at a time 
ifi 15 (%c = ^flcc < < At each step, the exponent error that is corrected in the add stage 

16 equals the /n-bit number currently being scanned {e^^y = Usually the error is 

17 resolved with one multiply using a pre-computed table of messages raised to all possible 

18 m-bit exponents. 

19 In greater generality, when the exponent error is "resolved" by 

20 multiplying from a pre-computed table, the exponent in the table is effectively 

21 subtracted from the current exponent error (the reduction stage: %^ = - e^. In the 

22 binary and m-ary methods, the reduction exponent is always chosen to equal the current 

23 error, so that the reduction always yields an error of zero {ei = However, a 

24 random exponent could be chosen to reduce the error as long as it was less than or 

25 equal the current error. The excess error would be carried into the next shift stage (e^rr 

26 = (eerr << m) + 
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1 Random Addition Chains : 

2 A library of functions (e.g., Addchain.{h,cpp}) can be created which 

3 describe a class that computes a random addition chain for a big number exponent. 

4 Computation of the addition chain assumes a storage mechanism, the "register store," 

5 that holds several big numbers (typically 15) and the original message. These registers 

6 store the message raised to various 29-bit exponents as well as the number that 

7 accumulates the message raised to the total exponent (the accumulation). 

8 The register store is primed with random exponents computed using 

9 random multiplications between already computed exponents, starting with the original 
Q 10 message in one of the registers. While accumulating e, multiplications between random 
iiS: 11 registers are performed and stored, so that "pre-computed" exponents are constantly 
pi 12 changing. These random multiplications are tuned so that register exponents do not 

13 exceed 29 bits. 

14 While accumulating, the exponent error is not allowed to grow more 

15 than twice as large as the largest exponent in the register store. If this limit is about to 
if; 16 be exceeded, the error is reduced. These "required" reductions prefer larger exponents 
\| 17 to keep the number of required multiplies small. "Optional" reductions randomly occur 
^ 18 if there exists any register that is less than or equal the current error. The parameters 

19 for these required and optional reductions are tuned so that about 700 multiplies occur 

20 for a 512-bit exponent in addition to the 512 necessary squarings - about 3 reductions 

21 for every 2 shifts. 

22 Since squarings are treated as multiplies, reductions are fairly 

23 unpredictable, and extraneous multiplies frequently occur, an opponent must track the 

24 contents of all the registers to determine the accumulating exponent. 

25 Register Store : 

26 Two categories of techniques are used to make it difficult to track the 

27 contents of a virtual register: data obfuscation and engineering tricks. Data obfiiscation 

28 involves storing registers redundantly, swapping data stored in two registers, and hiding 
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1 data by XOR'ing it with another register. Engineering tricks help defeat common 

2 techniques used for backwards engineering code, such as fall through cases on switch 

3 statements or extraneous no-op calculations injected between real calculations. 

4 Data Obfuscation : 

5 The register store contains 66 "real" registers that are used to store data 

6 for the 16 "virtual" registers used by the addition chain calculation. A virtual register 

7 can keep track of up to 4 redundant copies of its data with 4 "slots" that reference real 

8 registers. When data needs to be stored, a real register is randomly selected from the 

9 set of unallocated registers. Real registers are released to the unallocated store when a 

10 virtual register is overwritten. Dynamically allocating real registers to a virtual register 

11 prevents an adversary from statically examining data stored at particular memory 

12 offsets to determine the contents of the virtual register. 

13 When data is needed, one of the slots is randomly selected. Duplicating 

14 data for redundancy is scheduled randomly, but the process is biased to prefer data that 

15 has been used recently (ex. as a source or result of a multiply). Slots are sometimes 

16 released randomly, even though the data in the real register is not changed and might 

17 appear to be in use. This way, a virtual register's data may actually appear in more than 

18 4 real registers even though the system is only selecting data from one of the 4 slots it 

19 is tracking. 

20 In the process of copying data, a real register may also become XOR'd 

21 with another random real register, to mask its contents. The other register may or may 

22 not contain data that is being actively used. In fact, a copy operation may change the 

23 XOR state of up to four other registers, in addition to the real registers being copied to 

24 and from. These six registers can also swap their contents in various ways during a 

25 copy via a series of XOR's. Thus, a particular copy generally involves several XOR's 

26 that can change both the XOR state of several real registers and the real registers 

27 referenced by vutual register slots. 
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1 Dynamic register allocation, surreptitious swapping, and XOR'ing 

2 constitutes a kind of "shell game," where data is being shuffled around and masked in 

3 memory before and after virtually every multiplication. Data stored in one register may 

4 be retrieved from an entirely different register later on. The same register may never be 

5 used to retrieve the same piece of data twice in a row. The XOR'ing makes it more 

6 difficult to track the swapping in memory. 

7 Engineering Tricks 

8 Static analysis of the register store's memory is deterred in three ways. 

9 Memory is allocated on the heap so techniques that examine offsets from the stack 

10 pointer do not work. Random blocks of unused space are also added between real 

11 registers so that obvious offsets cannot be used to examine a particular register. 

12 Finally, the register store is initialized with random content so that unused or unprimed 

13 registers are not obvious by examination. 

14 The bulk of the code in rsagen.cpp is devoted to generating the _Copy 

15 function, and tracking the state changes that it performs as side effects. The _Copy 

16 function performs the copy /swap/state-change operation for the data in the register 

17 store. A single 32-bit unsigned integer is passed to __Copy that encodes the type of copy 

18 that is to occur. Part of this UINT encodes the 6-8 real registers involved in the 

19 copy/swap/state-change, and another part performs the actual calculation. Both of these 

20 parts are implemented with large switch statements (150+ cases) that make extensive 

21 use of fall through cases. Fall through makes it more difficult to analyze the code 

22 generated for the switch based on jumps, since 1 to 4 cases may use the same break. 

23 The major vulnerability of the system up to this point involves a dynamic 

24 attack, where the adversary breaks out of execution at each multiply and examines the 

25 data going in and out. If the adversary knows what exponent is represented by the 

26 source data, it can compute the exponent of the result. Since the whole system starts 

27 with the original message, the adversary could backwards engineer any exponent using 

28 this attack ~ most notably the secret exponent. 
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This IS deterred in two ways. First, data for the sources and result of the 




2 


multiply are directly read from and written to the register store, without making an 
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intermediate copy to stack memory. This makes it more difficult for an automatic 
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breaker to analyze the stack frame to infer exponents. Second, a percentage of the 
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calculations are performed using inlined copy cases and multiplies. These inlined 
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calculations mostly occur at the beginning of the computation, but other clusters are 
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scattered throughout the calculation randomly. With copies and multiplies mixed 




o 
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together, it should be more difficult to determine where exactly a multiply is occurring 
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and therefore where to examine data to backwards engineer exponents. 
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Vulnerability and Possible Solution: 
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Currently, the greatest vulnerability of the system is still the dynamic 
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attack. If an adversary can infer where multiplies are occurring m the mimed code, it 
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might still backwards engineer the exponents automatically. This will be difficult with 
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JBBT code shuftlmg and bogus code injected into the real calculations - but it is still 
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conceivable. 


ill 


16 


A number theory result could be used to make this more difficult. If 
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during a copy, the code performed a surreptitious add much like the swaps and XOR's, 


I I; 
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the code could mask a source value of the multiply. After the multiply, a second 
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number is added to the result, such that the total amount added is congruent to zero 




20 


with respect to the modulus. 
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Given (A+B) mod N = 0, it is needed to hide the sources and result of 
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the multiply: 
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(X*Y) mod N = 




24 


(X*Y + (A+B)*Y) mod N = 




25 


(X*Y + A*Y + B*Y) mod N = 




26 


((X + A) * Y + B*Y) mod N 




27 


So, add A to X before the multiply, and (B*Y) mod N after the multiply. It is possible 




28 


to add (B*Y) mod N after the mod - as long as the 512-bit number does not overflow 
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2 designed to support a surreptitious 

3 implemented in the state tracking code. 
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mod is done before the end. The copy code is 
add, although this new kind of state is not 
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1 CLAIMS 

2 WHAT IS CLAIMED IS: 

3 LA method of creating a computer program that uses a cryptographic 

4 algorithm to apply a cryptographic key to first data, said method comprising the acts of: 

5 identifying a set of actions that are performed in the course of 

6 using said cryptographic algorithm to apply said cryptographic key to said first data; 

7 generating a first set of computer-executable instructions which 

8 includes instructions to perform said actions; 

9 including said first set of computer-executable instructions in said 

10 computer program, wherein said computer program does not require access to said 

1 1 cryptographic key . 

12 

13 2. The method of claim 1, wherein said cryptographic algorithm is a 

14 public/private-key algorithm. 
15 

16 3. The method of claim 2, wherein said cryptographic key is the private 

17 key of an asymmetric key pair. 

18 

19 4. The method of claim 1, further comprising the act of receiving second 

20 data which in some way identifies or relates to a computing device on which said 

21 computer program runs, and wherein said first set of computer-executable instructions 

22 is based on said second data. 

23 

24 5. The method of claim 4, wherein said second data comprises or is 

25 based on one or more of the following: a CPUID associated with a processor of said 

26 computing device; a serial number associated with said processor; and third data which 

27 identifies a hard disk associated with said computing device, said third data being 

28 assigned to said hard disk by a manufacturer or distributor of said hard disk. 
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1 

2 6. The method of claim 4, wherein said first set of computer-executable 

3 instructions comprises one or more instructions which depend for their correct 

4 execution on the retrieval during execution of said second data. 
5 

6 7. The method of claim 1, further comprising the act of randomly or 

7 pseudo-randomly generating a number, wherein said first set of computer-executable 

8 instructions is based on said number. 

9 

10 8. The method of claim 1, further comprising the acts of: 

11 generating a diversionary second set of computer-executable 

12 instructions which perform one or more second actions; and 

13 including said second set of computer-executable instructions in 

14 said computer program. 
15 

16 9. The method of claim 8, further comprising the act of retrieving said 

17 diversionary second set of computer-executable instructions from a database of stored 

18 code. 

19 

20 10, The method of claim 8, wherein said computer program does not 

21 rely on performance of said second actions to apply said cryptographic key to said first 

22 data. 

23 

24 11. The method of claim 1, further comprising the act of generating a 

25 second set of computer-executable instructions which detects modification or deletion of 

26 at least a portion of code contained in said computer program, and which restores said 

27 portion if said portion has been deleted or modified. 

28 
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1 12. The method of claim 1, further comprising the act of reorganizing at 

2 least some code contained in said computer program. 

3 

4 13. The method of claim 1, further comprising the acts of: 

5 delimituig a segment of at least some code contained in said 

6 computer program; 

7 obtaining a first hash of the code inside the delimited segment; 

8 including said first hash of the delimited segment within said 

9 computer program; 

10 creating a second set of computer-executable instructions which 

1 1 obtahis a second hash of the delimited segment and which compares said second hash 

12 with said first hash; and 

13 including said second set of computer-executable instructions in 

14 said computer program. 

15 

16 14. The method of claim 1, further comprising the acts of: 

17 encrypting at least a portion of said first set of computer- 

18 executable instructions; and 

19 creating a second set of computer-executable instructions which 

20 decrypts said portion, 

21 

22 15. The method of claim 1, wherehi said act of creating said first set of 

23 computer-executable instructions comprises the acts of: 

24 creating instructions in a source-level language; and 

25 compiling said source-level-language instructions, 

26 

27 16. The method of claim 15, further comprising the act of postprocessing 

28 the compiled instructions after said compiling act, wherein said postprocessing act 
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1 comprises one or more of the following: encrypting at least a portion of the compiled 

2 instructions, and hashing at least a portion of the compiled instructions. 

3 

4 17. The method of claim 1, further comprising the acts of: 

5 receiving, from a computing device, a request for said computer 

6 program via a network; and 

7 providing said computer program to said computer device via 

8 said network. 
9 

10 18. The method of claim 17, wherein said network comprises the 

11 Internet. 

12 

13 19. The method of claim 17, wherein said receiving act occurs 

14 substantially contemporaneously with said providing act. 
15 

16 20. The method of claim 1, wherein said generating act comprises 

17 retrieving instructions from a database of stored code. 
18 

19 21. A computer-readable medium encoded with a third set of computer- 

20 executable instructions to perform the method of claim 1 . 

21 

22 22. A method of securely decrypting data with a cryptographic key, said 

23 method comprising the acts of: 

24 performing a first set of actions which apply said cryptographic 

25 key to said data, said first set of actions not requiring for their performance access to 

26 said cryptographic key; and 

27 performing a diversionary second set of actions different from 

28 said first set of actions; 
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1 wherein said first and said second sets of actions are implemented by way of a set of 

2 computer-executable instructions executable on a computing device. 

3 

4 23. The method of claim 22, wherein performance of said first set of 

5 actions does not depend on performance of said diversionary second set of actions. 
6 

7 24. The method of claim 22, wherein either of said first or second sets of 

8 actions in some manner relies for its performance on retrieval or derivation from said 

9 computing device of hardware identification data which identifies or in some way 
10 relates to hardware associated with said computing device. 

11 

12 25. The method of claim 22, further comprises the acts of: 

13 detecting a modification or deletion of at least a portion of said 

14 set of computer-executable instructions; and 

15 restoring said set of instructions to its state prior to said 

16 modification or deletion. 

17 

18 26. The method of claim 22, further comprises the act of decrypting at 

19 least a portion of said set of computer-executable instructions prior to executing said 

20 portion. 

21 

22 27. The method of claim 26, further comprising the act of re-encrypting 

23 said portion subsequent to executing said portion, 

24 

25 28. The method of claim 22, further comprising the acts of: 

26 deriving a value based on at least a portion of said set of 

27 computer-executable instructions; and 

28 comparing the derived value to a stored value. 
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1 

2 29. The method of claim 28, wherein said act of deriving comprises the 

3 act of hashing said portion. 
4 

5 30. The method of claim 22, further comprising the act of moving at 

6 least some of said computer-executable mstructions to a randomly or pseudo-randomly 

7 selected memory location on said computing device prior to execution of the moved 

8 instructions. 

9 

10 31. A computer-readable medium encoded with said set of computer- 

1 1 executable instructions to perform the method of claim 22. 

12 

13 32. A method of performing an action on a computing device in a 

14 manner that is at least partly resistant to modification or analysis, said method 

15 comprising the acts of: 

16 executing on said computing device a first set of computer- 

17 executable instructions that implements a sub-action, wherein performance of said 

18 action is in at least some way furthered by performance of said sub-action; and 

19 executing on said computing device a second set of computer- 

20 executable instructions that implements said sub-action, said second set of computer- 

21 executable instructions being different from said first set of computer-executable 

22 instructions. 
23 

24 33. The method of claim 32, wherein said action comprises applying a 

25 cryptographic key to first data. 

26 

27 34. The method of claim 33, wherein said action comprises using said 

28 cryptographic key to decrypt said first data. 
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35. The method of claim 33, wherein said action comprises using said 
cryptographic key to authenticate said first data. 

36. The method of claim 32, further comprising the act of executing a 
diversionary third set of computer-executable instructions different from said first and 
second sets of computer-executable instructions. 

37. The method of claim 36, wherein neither said first or second sets of 
computer-executable instructions relies for its correct performance on said diversionary 
third set of computer-executable instructions. 

38. The method of claim 32, further comprising the acts of: 

detecting a modification or deletion of at least a portion of said 
first or second sets of computer-executable instructions; and 

restoring the modified or deleted instructions to their state prior 
to said modification or deletion. 

39. The method of claim 32, further comprises the act of decrypting at 
least a portion of said first or second sets of computer-executable instructions prior to 
executing said portion. 

40. The method of claim 39, further comprising the act of encrypting 
said portion subsequent to executing said portion. 



41 . The method of claim 32, further comprising the acts of 

deriving a value based on at least a portion of said first or second 
sets of computer-executable instructions; and 
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comparing the derived value to a stored value. 

42. The method of claim 41, wherein said act of deriving comprises the 
act of hashing said portion. 

43. The method of claim 32, further comprising the act of moving at 
least some of said first or second set of computer-executable instructions to a randomly 
or pseudo-randomly selected memory location prior to their execution on said 
computing device. 

44. A computer-readable medium encoded with computer-executable 
instructions to perform the method of claim 32. 

45. A method of creating a computer program that is at least partly 
resistant to modification or analysis wherein said computer program performs a first 
action on at least two different occasions, said method comprising the acts of: 

creating a fu^st set of computer-executable instructions which 
performs said first action; 

including said first set of computer-executable instructions at a 
first location in said computer program; 

creating a second set of computer-executable instructions which 
performs said first action, said second set of computer-executable instructions being at 
least in part different from said first set of computer-executable instructions; and 

including said second set of computer-executable instructions at a 
second location in said computer program, 

46. The method of claim 45, wherein said first location is inline with 
code that requires performance of said action. 
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1 

2 47. The method of claim 45, wherein said first action comprises applying 

3 a cryptographic key to first data. 

4 

5 48. The method of claim 47, wherein performance of said first action 

6 does not require access to said cryptographic key. 

7 

8 49. The method of claim 45, further comprising the act of receiving 

9 second data which in some way identifies or relates to a computing device on which 
3 10 said computer program runs, and wherein said first set of computer-executable 
f I 1 1 instructions is based on said second data. 

3 12 

13 50. The method of claim 45, further comprising the act of randomly or 

IS 14 pseudo-randomly generating a number, wherein said first set of computer-executable 

15 instructions is based on said number. 

T:.. 16 

-I 17 51 . The method of claim 45, further comprising the acts of: 

3 18 creating a diversionary third set of computer-executable 

19 instructions; and 

20 including said diversionary third set of computer-executable 

21 instructions in said computer program. 

22 

23 52. The method of claim 45, further comprising the act of creating a 

24 third set of computer-executable instructions which detects modification or deletion of 

25 at least a portion of said computer program, and which restores said portion to its state 

26 prior to modification or deletion. 

27 
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53. The method of claim 45, further comprising the act of reorganizing 
said first or second sets computer-executable instructions or a combination thereof. 

54. The method of claim 45, further comprising the acts of: 

delimiting a segment of said computer program; 

obtaining a first hash of the code inside the delimited segment; 

including said first hash of the delimited segment within said 
computer program; and 

creating a third set of computer-executable instructions which 
obtains a second hash of the delimited segment and which compares said second hash 
with said first hash. 

55. The method of claim 45, further comprising the acts of: 

encrypting at least some instructions in said computer program; 

and 

creating a third set of computer-executable instructions which 
decrypts said encrypted instructions prior to their execution. 

56. The method of claim 45, wherein said act of creating said first set of 
computer-executable instructions comprises: 

creating instructions in a source-level language; and 
compiling said source-level-language instructions. 

57. The method of claim 56, further comprising the act of postprocessing 
the compiled instructions, wherein said postprocessing act comprises one or more of the 
following: encrypting at least a portion of the compiled instructions, and hashing at 
least a portion of the compiled instructions. 
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1 58. The method of claun 45, further comprising the acts of: 

2 receiving, from a computing device, a request for said computer 

3 program via a network; and 

4 providing said computer program to said computer device via 

5 said network; 

6 

7 59. The method of claim 58, wherein said network comprises the 

8 Internet. 

9 

10 60. The method of claim 58, wherein said receivmg act occurs 

1 1 substantially contemporaneously with said providing act. 

12 

13 61. The method of claim 45, further comprising the act of retrieving 

14 instructions from a database of stored code to be included in said computer program. 

15 

16 62. A computer-readable medium encoded with a third set of computer- 

17 executable instructions to perform the method of claim 45. 
18 

19 63. A method of creating a computer program that is at least partly 

20 resistant to modification or analysis, said method comprising the acts of: 

21 creating a fu-st set of computer-executable instructions; and 

22 creatuig a second set of computer-executable instructions which 

23 detects modification or deletion of at least a portion of said first set of computer- 

24 executable instructions and which restores said at least a portion if said at least a 

25 portion has been deleted or modified. 

26 

27 64. The method of claim 63, wherein said second set of computer- 

28 executable instructions perform a process comprising the acts of: 
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1 hashing at least a portion of the instructions in said computer 

2 program; and 

3 comparing the result of said hashing act with a stored value. 

4 

5 65. The method of claim 63, further comprising the act of receiving &st 

6 data which in some way identifies or relates to a computing device on which said 

7 computer program runs, and wherein said first or second set of computer-executable 

8 instructions is based on said first data. 
9 

:3 10 66. The method of claim 63, further comprising the act of randomly or 

ijl 11 pseudo-randomly generating a number, wherein said first or second set of computer- 

^ 12 executable instructions is based on said number. 
13 

£; 14 67. The method of claim 63, further comprising the act of creating a 

15 diversionary third set of computer-executable instructions which perform one or more 

;f; 16 actions. 

'4 17 

|S| 18 68. The method of claim 67, wherein said first and said second sets of 

19 computer-executable instructions do not rely for their correct execution on said 

20 diversionary third set of computer-executable instructions. 

21 

22 69. The method of claim 63, further comprising the acts of: 

23 creating instructions in a source-level language; and 

24 compiling the source-level-language instructions to produce said 

25 computer program. 

26 

27 70. The method of clarni 63, further comprising the acts of: 
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1 encrypting at least some instructions in said computer program; 

2 and 

3 creating a third set of computer-executable instructions which 

4 decrypts said encrypted instructions prior to their execution. 

5 

6 71 . A computer readable medium comprising: 

7 a first set of computer-executable instructions; and 

8 a second set of computer-executable instructions which uses 

9 error-correction techniques to detect variations of said first set of computer-executable 

10 instructions fi-om a reference state, and to restore said first set of computer-executable 
CP 11 to said reference state. 



.e 12 



13 72. The computer-readable medium of claim 71, wherein said reference 

14 state comprises the state of said first set of computer-executable instructions 

15 immediately after said computer-executable instructions are loaded into memory for 

16 execution. 

17 

18 73. The computer-readable medium of claim 71, wherein first set of 

19 computer-executable instructions are dynamically modifiable during their execution, 

20 and wherein said reference state comprises a state of said first set of computer- 

21 executable instructions at an intermediate point in time during their execution. 

22 
23 
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1 ABSTRACT OF THE DISCLOSURE 

2 A secure repository individualized for a hardware environment and a 

3 method and system for providing the same. The secure repository includes a hidden 

4 cryptographic key and code that applies the key without requiring access to a copy of 

5 the key. The code that implements the secure repository is generated in a manner that is 

6 at least partly based on a hardware ID associated with the hardware environment in 

7 which the secure repository is to be installed, and may also be based on a random 

8 number. Cryptographic fonctions implemented by the secure repository include 

9 decryption of encrypted information and validation of cryptographically signed 

10 information. The secure repository may be coupled to an application program, which 

1 1 uses cryptographic services provided by the secure repository, by way of a decoupling 

12 interface that provides a common communication and authentication interface for 

13 diverse types of secure repositories. The decoupling interface may take the form of a 

14 single application programmer interface (API) usable with multiple dynamically 

15 linkable libraries. 
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SYSTEM AND METHOD FOR PROVIDING SAME 

DECLARATION AND POWER OF ATTORNEY 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name; 
and 

I believe that I am the original, first and sole inventor (if only one name is Usted below) 
or aa original, first and joint inventor (if plural names are listed below) of the subject 
matter which is claimed and for which a 

El Utility Patent □ Design Patent 

is sought on the invention, whose title appears above, the specification of which: 
[X] is attached hereto. 

□ was filed on as Serial No. _• 

□ said application having been amended on • 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, includmg the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose to the U.S. Patent and Trademark Office all 
information known to be material to the patentability of this application m accordance 
with37C.F.R. §1.56. 

I hereby claim foreign priority benefits under 35 U.S.C. §1 19(a-d) of any foreign 
appUcation(s) for patent or inventor's certificate hsted below and have also identified 
below any foreign apphcation for patent or inventor's certificate having a filing date 
before that of any application on which priority is claimed. 
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I hereby claim the benefit under 35 U.S.C. §120 of any United States application(s) 
listed below and, insofar as the subject matter of each of the claims of this appHcation is 
not disclosed in the prior United States appUcation in the manner provided by the first 
paragraph of 35 U.S.C. §1 12, 1 acknowledge the duty to disclose to the U.S. Patent and 
Trademark Office all information known to be material to patentability as defined in 37 
C.F.R. §L56 which became available between the filing date of the prior application and 
the national or PCT international filing date of this apphcation. 

Serial Number Date Filed Patented/Pending/Abandoned 



I hereby claim the benefit under 35 U.S.C. §119(e) of any United States provisional 
application(s) listed below: 

Serial Number Date Filed 



I hereby appoint the following persons as attorney (s) and/or agent(s) to prosecute this 
application and to transact all business in the Patent and Trademark Office connected 
therewith: 
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Daniel D. Crouse Registration No. 32,022 
of MICROSOFT CORPORATION, One Microsoft Way, Redmond, WA 98052 and 
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Peter M. UUman Registration No. 43,963 

of WOODCOCK WASHBURN KURTZ MACKIEWICZ & NORRIS LLP, One 

Liberty Place - 46 Floor, Philadelphia, Pennsylvania 19103. 

Please address all telephone calls and correspondence to: 
Peter M, UUman 

WOODCOCK WASHBURN KURTZ 
MACKIEWICZ & NORRIS LLP 

One Liberty Place - 46^^ Floor 
Philadelphia, PA 19103 
Telephone: (215) 568-3100 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and the like 
so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 
of the United States Code and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 
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